这是什么类型的PR？

/kind feat

这个PR是做什么的/我们为什么需要它

打通 trace_id 链路的最后一跳：agentexecutor 是链路终点，也是此前 grep 断点——frontend 已把 X-Trace-ID 随 tunnel 请求透传进 loopback HTTP，yr 已把 YR_TRACE_ID/INSTANCE_ID/YR_RUNTIME_ID env 注入沙箱，但 executor 一处都没读，沙箱内日志无法与宿主侧全链路日志关联。

本 PR 在 executor 三个边界补齐打点（E1 请求级 / E2 启动级 / E3 进程级），并顺带解决探针稳态日志刷屏问题：

• E1（请求级）：文件四件套 + 5 个 sandbox 端点，每个请求 enter/exit 成对打点，frontend 与 executor 双侧同键可查。
• E2（启动级）：executor 进程启动即打三键齐全一行，是"create 链路到达 executor"的确认点。
• E3（进程级）：每条 bootstrap 用户进程拉起时打点，与 bootstrap_cmd_<i>.log 输出文件编号互相对应。
• 探针降噪：liveness 探针挂 yr runtime 1s 心跳（DEFAULT_PING_CYCLE=1000），稳态每秒一条 INFO 全天 ~8.6 万行刷屏；改为状态跃迁才打（HEALTHY 稳态静默，跃迁/subhealth/失败才打），错误路径日志保留。

此PR修复了哪些问题

Fixes #6

PR对程序接口进行了哪些修改？

1. E1 请求级打点（executor/src/yr/agentexecutor/http_server.py）

新增 _agent_trace contextmanager 统一包裹：

[agent.<op>.enter] agentexecutor path=<route> trace_id=<..> instance_id=<..>
[agent.<op>.exit]  agentexecutor result=<HTTP:<status>|ERR> cost_ms=<..> trace_id=<..> instance_id=<..>

• trace_id 取请求头 X-Trace-ID，instance_id 取 env INSTANCE_ID；空值字段整体省略，格式不变（沙箱内用户进程直连无头时兼容）。
• <op> ∈ upload|download|filelist|mkdir + 5 个 sandbox 端点（op 取路径末段）；/healthz 心跳不打，避免刷屏。
• exit 行经 send_response override 记录状态码，try/finally 保证异常路径也成对。
• 重复日志降级：access log、client 断连、download range 拒绝三处降为 DEBUG——结果已由 exit 行表达，避免双写。

2. E2 启动行（executor/src/yr/agentexecutor/runtime.py）

AgentExecutorRuntime.start() 打一行：

[agent.start.enter] agentexecutor trace_id=<YR_TRACE_ID env> instance_id=<INSTANCE_ID env> runtime_id=<YR_RUNTIME_ID env>

supervisor 与 docker 两种 sandbox_type 均打（只依赖注入的 env，与 executor 类型无关）。sandbox_id 不在沙箱内重复感知——由宿主侧既有日志关联（supervisor 路径 jiuwenbox 并列行；docker 路径 containerID 行）。

3. E3 bootstrap 行（executor/src/yr/agentexecutor/process_manager.py）

拉起每条 YR_RUNTIME_BOOTSTRAP_CMD 时，与既有 started user process 行合并增强（不新增两条）：

started user process pid=<pid> bootstrap_index=<i> argv=<argv> trace_id=<..> instance_id=<..>

bootstrap_index 与统一后的 ${GLOG_log_dir}/${YR_RUNTIME_ID}/bootstrap_cmd_<i>.log 输出文件编号对应——grep 到日志行即可定位对应进程输出文件。

4. 探针日志降噪（executor/src/yr/agentexecutor/probe.py）

• liveness 改为状态跃迁才打：新增 _log_liveness_state(state, detail)，记录 _liveness_last_state，同状态重复 → DEBUG，跃迁 → INFO，转 FAILED → WARNING（含失败原因）。
• DISABLED 分支（startup 门期间/未配置）→ DEBUG；startup 每次尝试失败 → DEBUG（最终失败已有既有日志）。
• 保留关键流程 INFO：liveness probe configured、startup probe waiting initial_delay 等启动序列线保留，探针仍可从日志看清流程。

环境变量（只读，均为 yr 侧注入，executor 不新增）

与其他模块的相关性描述

• frontend（配套 PR）：E1 的 traceid 来自 frontend 随 tunnel 请求透传的 X-Trace-ID 头。
• functionsystem（配套 PR）：E2/E3 的三键来自 build.cpp GeneratePosixEnvs 注入的 env；E1 的请求来自 frontend 文件/sandbox API 经 tcp.tunnel 转发。
• executor 是平台托管组件（预装 Agent 基础镜像），日志变更只影响 agent 沙箱，不波及通用 FaaS 链路；不依赖 yr 包。

测试

• 单测：tests/executor/ 84 项全通过。新增覆盖：sandbox 端点 enter/exit 成对与 trace 字段、空值字段省略、/healthz 静默、E2 启动行三键、E3 行 bootstrap_index 与 trace 后缀、liveness 跃迁才打（HEALTHY 稳态静默 / SUBHEALTH→HEALTHY 跃迁两条回归用例）。
• 端到端（hhc-compile 容器，自验脚本 self-verified/0016-traceid-selftest.sh，37/37 PASS）：create 带 X-Trace-Id 后，runtime 日志命中 E2 启动行（三键齐全）、E3 bootstrap 行、E1 文件操作行（mkdir HTTP:200 / download 404 失败路径也成对打点）。
• 刷屏消除：实例 RUNNING 稳态下 liveness 不再每秒打 INFO，仅状态变化时输出。

自验结果