Self-host M5: docker-exec tar-fallback should persist compiled driver artifacts to avoid Zend fallback

[PurHur]

Milestone

M5 (retire Zend from the loop) — parent #1492.

Problem

On harness hosts where ./script/docker-exec.sh must use tar-copy fallback, build/ artifacts produced in one invocation do not persist into the next container. As a result:

• north-star5 step 4b (lib spine smoke link) can’t find an executable compiled driver and falls back to gen-0 Zend (Self-host M5: north-star5 step 4b still falls back to gen-0 Zend for lib spine smoke #2958).
• vendor prelink step 5 often resolves compile invoker=zend (Self-host M5: north-star5 step 5 vendor prelink --compile must use native invoker (no Zend) #2962).

This is not a compiler bug per se; it’s the harness wrapper discarding the compiled driver between steps.

Scope

• script/docker-exec.sh
  • Extend tar-fallback to optionally sync back a small, explicit set of build artifacts (e.g. build/bin-compile-aot, build/selfhost-*), similar to how it syncs inventory docs.
  • Or provide a documented --sync-back preset for self-host ladders (M5) so multi-step scripts can keep native drivers.

Repro

docker info >/dev/null
# Run M5 presenter in an environment where docker-exec prints:
#   docker-exec: bind-mount incomplete; copying repo via tar...
./script/docker-exec.sh -- bash -lc './script/north-star5-verify.sh --strict'

# Observe Zend fallback in step 4b and/or invoker=zend in step 5.

Done when

• In tar-fallback mode, a full north-star5-verify.sh --strict run does not need gen-0 Zend fallback purely due to missing build/ artifacts.
• If sync-back is enabled, bootstrapVendorPrelinkResolveCompileInvoker() sees build/bin-compile-aot as executable in later steps.

Labels

Suggested: self-host, bootstrap, IMPORTANT.

[PurHur]

claim: cursor-agent-lane-c — starting this run