#3972 Extension consumers keep the publisher's bundle: pull, update and auto-resolve stop rebuilding (direction A for #3634)

Repo: swamp. Step 3 of the extension dependency-forms design. Closes #3634 (direction A, decided by Seth 2026-10-26). Depends on #3970 and #3383. Design: the extension dependency-forms Doc, https://claude.ai/artifact/WpRbpqb5djPgDXzydFSohs (decided 2026-10-26).

Problem

extension install runs the publisher's bundle. extension pull, update, auto-resolve and serve upgrade throw it away and rebuild from shipped source on the consumer's machine. No recorded decision is behind that: pull goes through the install service's phase 8 without trustPulledCache. So consumers run different bytes depending on the command, and a rebuild costs 0.5 to 1.4 s per extension on a cold cache (measured 2026-10-26, best-case machine).

Proposal

• Pull, update, auto-resolve and serve upgrade keep the archive bundle, as install does. The loader already has trustShippedBundles, which push uses.
• Rebuild from the pinned source only when the bundle's BUNDLE_LAYOUT_VERSION or host-zod expectations don't match the consumer's swamp, and pass --no-config when it does.
• Push records the bundle's SHA-256 in the v2 record (S2), and pull checks it. A mismatch is refused.
• Workers and Docker keep their own zod-inlined build from the pinned source.
• Supply-chain mitigation: #3383 (safety analysis scans the bundle, not only the source) lands first. The registry is a middleman that passes on what the publisher built.

Acceptance

• Pull and install of one version leave identical bundle bytes.
• A layout-version mismatch falls back to a rebuild at the pinned versions.
• A bundle whose hash doesn't match the record is refused.
• A worker run still uses a zod-inlined bundle.
• UAT: a swamp-uat item covering consumers running the publisher's bundle (U4 in the Doc), including a finding planted only in the bundle that the bundle scan reports.