docs(web): record bounded release rollout

vehicle-data-platform/docs/frontend-production-readiness.md

@@ -52,6 +52,8 @@ The production build now emits `.release-assets` itself and verifies that it lis
 
 `install-web-release.sh` stages an immutable directory, validates archive paths, atomically replaces the `current` symlink, restarts the service, verifies every current and compatibility asset byte-for-byte, checks the authenticated runtime release and only then prunes history to 20 releases. Any readiness, asset or health failure restores the previous symlink, release environment and service before returning an error. Tests exercise successful installation, bounded compatibility generations, unsafe input, missing assets, release pruning and a forced post-switch rollback.
 
+Production release `bounded-release-history-20260716041827` passed 19 current and 19 immediate-previous asset checks before pruning. Release history fell from 748 directories / approximately 12 GB to 20 directories / 2.1 GB, releasing approximately 9.9 GB without touching business data. The authenticated health endpoint reported the new release, the service remained active with no critical log entry, and a signed-in `tracks -> history -> monitor` navigation smoke rendered meaningful content on every route with no framework overlay, warning or error.
+
 This applies the same lifecycle principles as blue/green deployment: stage a separate revision, validate it, switch traffic and retain a bounded rollback history. AWS documents fast rollback by switching back to the blue environment, while Kubernetes exposes `revisionHistoryLimit` because unbounded old revisions consume control-plane resources: <https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html>, <https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit>.
 
 ## 2026-07-16: cancellable, off-main-thread mileage export