A release date enforced at the edge, not announced on a page

What was wrong before this entry: a release date is a claim about the future, and the storefront made it while the bytes contradicted it. The two free packages were static assets served by the edge platform's asset layer, which answered any direct request with the file, cached. A visitor who read the page saw a date; a visitor who guessed the path got the download. The page and the bytes disagreed, which on this platform is the defect class everything else exists to prevent.

The cure is one constant in one file, read by both runtimes. The storefront reads it to decide whether to render the download control or a chip that names the date and counts down to it live. The edge worker reads the same constant and, for any request to a package path before that instant, answers 423 Locked with the release time in the body and a Retry-After header, and never touches the asset layer. The first deploy of that worker did not take effect: the platform's asset layer answered the package path before the worker ever ran, and the cached file came back 200. The worker's configuration now routes those paths through the worker first — and the assets upload session had to be reopened to do it, because the completion token of the previous session is single-use. Witnessed after the fix: both package URLs answer 423 with the release instant; the manifest and the homepage answer 200.

The gate is time-based on purpose. There is no human awake at nine in the morning to flip a switch, and a switch would be one more control that could be forgotten. At the instant the constant names, the same code path serves the file; nothing is redeployed, and nothing has to be remembered.