Let Core own the runtime history window

[SaladDay]

What

Session Runtime history now takes a named range (1h default, 6h, 24h) instead of start, end and max_points. Core ends the range at the last bucket boundary on its own clock, so the request carries no time and the browser needs no clock.

• Core:
  • runtimehistory.Capabilities.Window builds the range: the bucket width comes from the range and 120 points, the end is Core's time rounded down to a whole multiple of that width in Unix seconds, and the start is the end minus the range.
  • GET .../runtime-history?range= uses this window. Any other parameter, a repeated range or an unknown value returns 400 invalid_request.
  • Core builds the range itself, so a range the history service rejects is now a 500 internal_error instead of the caller's 400.
  • Core metrics, node detail and runtime history now share one rangeName query reader. Only runtime history had the end > now check; the other two already used Core-owned named ranges.
• Contract: the swag annotation and core.openapi.yaml updated via make openapi, and the "Session Runtime history" section updated in runtime-observability-api.md (EN and zh, refreshed source_hash).
• agents-client: retrieveRuntimeHistory(projectId, sessionId, range, options) with a RuntimeHistoryRange type. The projection checks that the echoed requested_range has the requested length.
• Web:
  • Sandbox metrics and the Session Runtime section pass the range label straight through. The now, rangeStart, rangeEnd, loadedAt and RUNTIME_DURABLE_MAX_POINTS values had no remaining consumer and are removed.
  • Parallel per-Session reads can straddle a bucket boundary, so the merged trend keeps only the buckets every history covers.
  • Errors go through readError, so a typed Core code shows in the console's language. Web's own read-bound errors (more than 24 Sessions, mixed bucket widths) now have en and zh-CN copy too.
  • The page-level history query no longer retries, because the 30-second poll already does. Each Session is read once per poll.
  • The Session Runtime section keeps retryTransient: it reads one Session, and when the Session is not active nothing polls, so one retry on a 5xx or network failure is its only recovery. 4xx responses are not retried.

Why

When the browser clock was more than 1 s ahead of Core's, every runtime-history read returned 400 "Runtime history range is invalid.", and the zh console showed that English message. Each failed read was also sent twice: the global retry: 1 retried the 400.

Sandbox metrics layout, cards and tables are unchanged.

Verification

• go build ./services/core/...: pass.
• go test ./services/core/internal/api/ -run 'RuntimeHistory|HeadRuntime|AdminRuntime|CoreErrorCatalog|CoreMetricsAdministratorContract|SandboxNodeDetailValidationAndAuthentication': pass. This includes the new acceptance test TestRuntimeHistoryRangeEndsOnCoreClock.
• go test ./services/core/internal/runtimehistory/: pass.
• go vet ./... (module-wide): clean.
• make openapi, then make check-openapi: no drift, and the generator tests pass. go test ./contracts/agents-api/v1/: pass.
• pnpm --filter @oac/web typecheck: pass. vitest run on runtime-history.test.ts, session-history.test.ts and core-error.test.ts: 34 passed.
• packages/agents-client: pnpm typecheck passes. vitest run on runtime-history.test.ts and admin-client.test.ts: 117 passed.
• Docs:
  • make check-docs: pass.
  • make check-names: pass.
  • website check-translations: pass (coverage, freshness and structure).
• Browser, on the fixture Core with Playwright, zh and en at 1440 and 390 px. The Sandbox metrics page, the Runtime dialog and the node dialog were each loaded against four mocked runtime-history replies: 200 from a Core clock 5 minutes behind the browser, 400, 503 and 404. In every case the network log showed exactly one ?range=1h request per Session; before the change there were two. Charts render with the skewed clock, and the zh 503 message is localized.

Skipped

• Full make check: lane rule is focused checks only.
• Playwright acceptance suite (check-web-acceptance).
• Postgres integration tests (check-core-integration). The PG reader is unchanged.
• Live E2B and microsandbox runs: not needed for a read-path change.