Steps that passed by timing luck

Two failures with the same shape, both from a release pipeline:

• A loop wrapped one disk image per architecture. Each iteration mounted a volume under the same name. Releasing a volume is asynchronous, so the next mount either failed as busy or — worse — quietly mounted under a suffixed name while the script kept writing to the hardcoded path.
• A build step downloaded a native archive through the standard library's URL stream. The download answered with a redirect to a mirror; on a cross-protocol redirect the stream API saved the error page body as the target file and returned normally.

Neither is a race you introduced. Both are steps that were always wrong and were being covered by how fast the machine happened to be. A runner image update changes the timing, and they start failing — which is why the commit that "breaks" them is usually unrelated.

The expensive shape is not "fails intermittently", it is "succeeds while producing the wrong artifact." A hard failure costs one re-run. A step that reports success and hands the next job a zero-byte file, an error page, or an empty mount point costs an afternoon, and the traceback points somewhere it did not come from.