The leak gate refused a deploy, and it was right

What was wrong before this entry: the deploy ran the build framework's Cloudflare adapter, and that adapter's environment extractor reads the repository's env files at build time and bakes their values into the worker bundle as a convenience. The repository's env file carried one variable that nothing in the code reads. The bundle therefore contained a value the source never asked for — the exact class of defect the client-leak gate exists to catch. It caught it, named the variable, and refused to upload. The site stayed on its previous worker.

Two cures were available. Delete the variable from the env file, which fixes today's instance and leaves the mechanism armed for the next one; or take the baker's input away. The second was chosen. The deploy script now renames every env file the extractor is documented to read — the base file, the local override, and the per-mode variants — to a hold suffix for the duration of the build, runs the build, runs the leak gate, deploys, and restores the files in a finally block that also fires on an interrupt or a termination signal. The deploy credential itself is never in any of those files; it is passed to the deploy tool from a file outside the extractor's list, and that file is not printed, echoed or read by anything but the deploy tool.

The gate did not change. Its patterns, its exit code and its position in the pipeline are what they were; a deploy that would bake an env value into a bundle still stops before upload. What changed is that the pipeline no longer creates the condition the gate is for. A guard that fires is working; the correct response is to remove the cause, not the guard.