BLOCKER: Render production is not advancing from stale commit #209

Current production state

Render service: network-map-tool-mqib
Production URL: https://network-map-tool-mqib.onrender.com

As of 2026-08-08 UTC:

• Expected current main: f1f13bb537e7b6075d4064bca8c356e8ea7649e4
• Production /api/health reports deployed commit: 60c56e49c61a9c8651f55741f9ba245adbef7a0e
• That deployed SHA is the merge commit for PR Allow user-defined labels for provider dataset uploads #166, Allow user-defined labels for provider dataset uploads.
• Before Harden production revision verification against false positives #208 merged, current main was already 213 commits ahead of that production SHA.
• /api/revision returns the SPA HTML shell instead of JSON.
• /api/ready returns the SPA HTML shell instead of JSON.
• Therefore production predates the current deployment identity/readiness routes and the cumulative Land cumulative Network Map hardening and finalized desktop UI #205/Finish desktop startup resilience on finalized hardening stack #206 hardening.

What is already green in GitHub

The cumulative desktop hardening was promoted through #205, startup resilience through #206, and the production-verifier false-positive fix through #208. The validated desktop matrix includes Chromium, Firefox, and WebKit across both standard and P2 routes, plus API/database acceptance, UI acceptance, post-idle renderer probes, and Validate.

Important verifier correction

During production verification we found and fixed a false positive in production-exact-revision-acceptance.mjs: an empty deployed revision could match because expectedSha.startsWith("") is true. #208 now requires a non-empty revision, JSON content type, explicit readiness, and preserves raw endpoint evidence.

Likely deployment-side cause

Git pushes to main are not currently reflected by the live service. The deployed boundary being exactly PR #166 is consistent with the service being pinned or Auto-Deploy not advancing. This is evidence, not a claim about the exact Render setting until the service configuration/deploy history is inspected.

Do not close until all are true

• Render deploys the latest intended main revision.
• /api/revision returns JSON containing the exact deployed Git SHA.
• /api/ready returns JSON with ok: true.
• The deployed SHA equals current main.
• Read-only production desktop acceptance passes for standard and ?p2-preview=1.
• No production API writes occur during acceptance.
• Auto-deploy behavior is confirmed so future merges do not require repeated manual deployment.

Supersedes the operational tracking purpose of PR #165. No production deploy or Render configuration change is performed by this issue.