Activate Reader App Health endpoint key and verify live receipt

[sarthakagrawal927]

Why

Reader's App Health endpoint SDK shipped in #58 and the production Worker has an APP_HEALTH_INGEST_KEY binding, but App Health's Reader / production environment shows no active private key and no accepted endpoint receipt. A live GET /api/tags returned its expected 401 after deployment, yet the owner dashboard remained at “Waiting for the first valid API monitoring event.” The existing binding must not be treated as proof that it maps to this imported App Health environment.

What

Reconcile the Reader Worker binding with the Reader / production App Health environment using the platform's write-only key flow, then verify one real request is accepted and appears in the authenticated Backend view. Preserve request privacy and ordinary response behavior. Do not print or store the key in a shell command, issue, PR, logs, or source.

Acceptance

• Reader / production shows an active private key in App Health metadata.
• A production API request yields a fresh accepted endpoint receipt in the Reader / production Backend view, with route template, status, and request units.
• Record the exact production Worker version and dashboard freshness, without exposing key material.

Current source SHA: 54bab0d6229e224be4a7acbf2cb2361986ee54b6; production Worker version: d5a9b2e1-0672-4da3-86bf-a68b15740b8b at 100% traffic. Main CI and manual production deploy run both passed.

[sarthakagrawal927]

Local source review found one additional endpoint-observation gap at current main 54bab0d: Reader's public GET/HEAD /api/ai discovery response returned before the Hono App Health middleware. A small uncommitted worktree patch now routes that discovery response through Hono while preserving its response behavior. Focused worker and App Health tests pass (5/5), typecheck passes, pnpm check passes with existing warnings, and pnpm docs:check passes. This is local source work only: no commit, push, deployment, key change, or live receipt is claimed. The issue's production key/environment acceptance remains open.

[sarthakagrawal927]

Production telemetry acceptance update (2026-09-30 UTC):

• Reader's canonical private ingest key was bound to the Reader / production App Health environment (app-import-126da40da98ff062b1a644b460fe99614c95a45c614569ff8e76257f5610068d) at 06:04:24Z. No key material is recorded here.
• PR Route public AI discovery through App Health #60 merged as 57979189f49c87abad8a586f10e12c92ca92e51e; manual production deploy run 36676215177 passed. Its source-tagged Worker version is c59c46ac-7539-4c32-a4b5-c26e4acb170d at 100%.
• After key binding, Cloudflare created version b212e27a-ba48-4161-9e29-897bd50b379d at 06:04:27Z as a secret change and reports it at 100%. Its script etag matches the source-tagged deployment exactly (eb16c5c29cfa6fe382dbdc46429246e2af2718ae148b8954d1427bf5de0bd957); its metadata includes the APP_HEALTH_INGEST_KEY binding.
• A fresh ordinary GET /api/ai returned 200 JSON at 06:06:14Z. The canonical App Health D1 rollup then recorded Reader/runtime/worker with first_seen=last_seen=1790748374361 (06:06:14.361Z), request_count=1 in the 60-second rollup; 14 requests are on record overall.
• The change only routes the public discovery GET/HEAD through Hono App Health. The response remains the same public discovery JSON; hosted Reader submissions and stored reader content were not changed.

The production receipt and release/version evidence are now verified. The owner is separately checking the authenticated Backend dashboard freshness display before closing this issue.

[sarthakagrawal927]

Dashboard acceptance verified: the authenticated Reader / production Backend dashboard was freshly reloaded at approximately 06:07Z on 2026-09-30. It showed the new one-request Reader production receipt, 0% errors, and p95 below 1 ms, matching the canonical D1 rollup. The dashboard is receiving current Reader endpoint telemetry.