[miguel-heygen]

What

Every cold chunk on the arm64 video function used to unpack the compressed Chrome (and its fonts, graphics libraries and system libraries) into /tmp before its first browser launch. The staging step now unpacks them once, into chrome/ in the image, and chromium.ts uses that copy when it exists: it points Chrome at it and sets FONTCONFIG_PATH and LD_LIBRARY_PATH the way @sparticuz/chromium does for /tmp. Fonts go to fonts/, the directory its fonts.conf already lists.

Images or zips without chrome/ (the x86 zip, SAM local) keep the existing unpack path unchanged. The compressed files stay in the image as the fallback.

Checks

• Staging test builds a fixture pack and asserts the unpacked layout (arm64 ELF, executable bit, fonts, graphics libs, system libs).
• chromium.test.ts asserts the prepared copy is used, @sparticuz/chromium is never asked to unpack, and LD_LIBRARY_PATH is not prepended twice.
• Real pack (sha256-pinned) inflates to the same layout @sparticuz/chromium writes to /tmp.
• A scratch-stack A/B on identical renders (cost, wall, output hash) follows in a comment.

Also in this PR

• The deploy warm-up invoke reads the whole unpacked Chrome, so the lazily loaded image has its blocks cached before the first render.
• A slow first Chrome launch no longer pins a chunk to screenshot capture. The BeginFrame probe now reports timedOut separately from a real rejection; on a timeout only, the browser is relaunched and probed once more with a longer budget before falling back. A rejected HeadlessExperimental command still falls back at once. Tests fail on the previous browserManager.ts (3 of 3 new tests).

[github-actions]

Edit accuracy did not run: 0 of 5 shards reported results; see the shard jobs.

Nothing was compared with the base branch.

[miguel-heygen]

Closing: the saving on later renders does not justify the slower, costlier first render after each new image. The beginFrame probe retry from this branch will land on its own.