feat: add read-only strategy health dashboard

[Pigbibi]

Summary

• add the strategy_health_dashboard.v1 schema and dedicated Worker sync/read APIs
• store normalized snapshots in KV with allowlisted reads, stale handling, and fail-closed empty states
• add the default read-only strategy health view while preserving /api/switch
• normalize quant-monitor output and add an opt-in publisher with legacy CLI/output-dir compatibility

Safety

• dedicated health sync token; no workflow token reuse
• no broker/order/live behavior changes
• no Cloudflare deployment or secret changes in this PR
• no innerHTML for dynamic UI content

Test plan

• QuantRuntimeSettings Python tests and Worker tests
• quant-monitor snapshot/publisher tests
• local desktop/mobile browser smoke

[github-actions]

🤖 Codex PR Review

✅ Merge allowed: blocking findings were cleared by independent Codex arbitration

⚖️ Codex Review Arbitration

✅ clear: The current finding is disproven by the PR’s own contract evidence. In web/strategy-switch-console/worker.js, /api/strategy-health intentionally computes top-level snapshot freshness from the earliest available snapshot timestamp (Math.min over generated_at and computed_at), and tests/strategy_switch_worker_validation.mjs explicitly sets a fresh generated_at with an old computed_at and asserts the response becomes data_status: "stale". That test makes the reviewed behavior the expected contract, not a bug. The added schema and README also separate top-level snapshot status from per-strategy freshness, which is consistent with treating an old computation time as making the published snapshot stale. The prior blocking finding is also addressed independently by the new future-timestamp fail-closed path (futureBeyondClockSkew => stale), so there is no contract conflict.

ℹ️ Other Findings

1. 🟡 [MEDIUM] Reliability in web/strategy-switch-console/worker.js

readBoundedJson() claims to enforce a 256 KB max body, but it still calls await request.arrayBuffer() before rejecting oversized uploads. That means an oversized request is fully buffered in memory first, so a large or malicious payload can still consume worker memory/CPU and degrade the instance before the 413 is returned. (line 1151)

Suggestion: Read the body as a stream and stop once maxBytes is exceeded, or put a platform-enforced request-size limit in front of this route so oversized bodies are rejected before buffering/parsing.

---

Review by Codex PR Review bot • PR

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a961d4e983

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject snapshots that omit data_status

If a publisher sends a snapshot that otherwise contains strategies but omits data_status (or sends it empty), this defaults the status to unavailable; the next branch then skips all strategies, writes a zero-count summary, and returns a successful sync. Since the new schema makes data_status required, malformed publishes should fail fast instead of silently replacing the dashboard with an empty unavailable snapshot.

Useful? React with 👍 / 👎.