Hardlink/CAS flush

Speed up write-back by hardlinking (or content-addressing) the flush instead of byte-copying produced files from the sandbox upper to the host.

Why not: The flush crosses a filesystem boundary: the overlay upper lives on tmpfs and the host working dir is on disk. Hardlinks cannot span filesystems, so the apply step's copy is a full byte copy by necessity — there is no link to substitute. A CAS layer would not help either: write-back only flushes a command's produced files (dist, tsbuildinfo, a migration), which are new bytes by definition, not dedupable against an existing store. The dep tree, which is shared, already lives behind the CAS dep store and never flushes (it stays in the read-only snapshot lower).

Revisit only if the flush is ever measured as a material fraction of a write-back run's wall-clock (today persist sits within noise of the plain os build) and the upper and host are co-located on one filesystem so reflink/copy_file_range becomes available.

CI wall-time gate

Fail CI when a benchmarked path is slower than the native baseline by some threshold.

In-process async vfs runs

Drain a controlled microtask/timer loop so async pure-JS runs stay on the no-spawn vfs path instead of bailing to native.