fix(gateway): proxy sandbox-routed envd metrics requests

[feimingxliu]

What

• Allow exact /metrics requests carrying sandbox routing headers to follow the existing Gateway -> runtime node -> sandbox proxy path.
• Allow host-based sandbox proxy domains to route /metrics to the selected sandbox port.
• Keep unrouted /metrics unavailable on the Gateway public HTTP listener.
• Include sandbox-routed /metrics requests in Gateway HTTP instrumentation while continuing to skip the local reserved endpoint.

Why

The Gateway currently returns 404 for every exact /metrics request before it parses host routing, sandbox headers, or scheduler bindings. This blocks the existing envd GET /metrics endpoint even when the caller supplies a valid sandbox ID and target port.

The runtime node proxy already supports the remaining path: the Gateway prefixes the request as /proxy/metrics, and the node strips /proxy before forwarding it to the sandbox interaction IP and requested port.

Related issue

Closes #151

Related but not equivalent: #5 tracks the unimplemented E2B sandbox metrics API. This PR only fixes generic proxy access to the existing raw envd endpoint.

Scope and non-goals

Included:

• Gateway classification for exact /health and /metrics reserved paths.
• Header-based and host-based sandbox routing for /metrics.
• Stable local and malformed-request behavior.
• Gateway HTTP instrumentation classification.

Not included:

• E2B GET /sandboxes/{sandboxID}/metrics or aggregate sandbox metrics endpoints.
• Changes to envd, scheduler APIs, node proxy behavior, or Prometheus listener configuration.
• New authentication, configuration, or generated protocol surface.

Design and behavior changes

For exact /health and /metrics, the Gateway now resolves the routing boundary before choosing local behavior:

sandbox headers or proxy host
  -> LookupNode
  -> runtime node /proxy/{path}
  -> sandbox service on the requested port

no sandbox route
  -> /health: 204 from the Gateway
  -> /metrics: 404 from the Gateway public HTTP listener

A routing header set that omits the sandbox ID continues to return 400. Invalid host-based routes continue through the existing proxy error mapping.

Gateway Prometheus metrics remain on the separate metrics listener, default :9102; this PR does not expose them from the public HTTP listener.

Compatibility and operations

• Public API or generated protocol: no schema or generated-code changes.
• Configuration or defaults: unchanged.
• Snapshot manifest, artifact layout, or storage format: unchanged.
• Upgrade and rollback: behavior-only Gateway change; rollback restores the previous unconditional 404.
• Host requirements, permissions, ports, or dependencies: unchanged.

Validation

• make fmt
• make clippy
• make test-unit
• Relevant Rust integration tests
• make -C services test (required when services/ changes)
• Generated clients/server regenerated with the documented make target
• Documentation updated
• Benchmarks or performance comparison completed

Commands and results:

go test ./gateway/internal
ok   agentenv/services/gateway/internal

make -C services test
PASS: gateway and scheduler packages

make -C services fmt-check
PASS

make -C services vet
PASS

git diff --check
PASS

Skipped checks and reasons:

• Rust formatting, clippy, unit, and integration checks: no Rust code changed.
• Generated clients/server: no OpenAPI or protobuf source changed.
• Documentation: existing proxy documentation already states that header-routed and host-routed sandbox requests forward their original paths; this fix makes /metrics conform to that contract.
• Benchmarks: request classification adds no new I/O or algorithmic path.

Risks and reviewer notes

The main compatibility boundary is preserving the reserved local endpoints. Tests verify:

• header-routed /health and /metrics reach /proxy/health and /proxy/metrics on the selected runtime node;
• host-routed /health and /metrics inject the sandbox ID and target port;
• unrouted /metrics remains 404;
• target-port-only /health and /metrics remain 400;
• only local /health and /metrics bypass Gateway HTTP instrumentation.

Checklist

• The PR contains one coherent change and no unrelated formatting or refactoring.
• New behavior is covered by tests, or I explained why testing is impractical.
• Logs and examples contain no credentials, tokens, or private registry information.
• I did not manually edit generated code without updating its source and regenerating it.

[github-actions]

✅ OpenCodeReview: Review complete: 0 finding(s) across 2 selected item(s).

[feimingxliu]

Live validation completed on a single-node x86_64 PVM k3s environment using a test-only Gateway image built from commit b1e9b0e.

Results against a real running sandbox:

GET /metrics + x-agentenv-sandbox-id + x-agentenv-target-port: 49983 -> 200
GET /metrics + E2B routing header aliases                         -> 200
GET /metrics + target port only                                   -> 400
GET /metrics without sandbox routing                              -> 404
GET /health without sandbox routing                               -> 204

The routed response was the envd JSON payload and included ts, cpu_count, CPU usage, memory, and disk metrics. Gateway Prometheus output also recorded the routed requests under route_source="header", while the unrouted reserved endpoint remained unavailable on the public listener.

The Gateway rollout completed with 1/1 Ready and zero restarts. Scheduler and runtime workloads were not changed. The temporary sandbox was deleted after validation, and no Gateway warning/error logs were observed.

[LSX-s-Software]

@guozy18 Could you please take a look? It seems that the related code was originally written by you.