CL-6324 step 3: the sidecar deploys from the closure

[TheGreatAxios]

The execution host comes off the retired workflow.json lineage. A deploy
materializes the frame's frozen closure, evaluates the pinned code, and runs
that; the boot-time restore replays the same pin through the same helper, so
both paths reach the runnable definition by one computation rather than two
that can drift.

bun run typecheck exits 0 repo-wide on this branch — the 24 sidecar errors
the conversion table named are gone.

What landed

• Closure staging (workflow-host-wiring/closure-staging.ts): the durable
  per-deployment source stores (siblings of the reclaimed instance dir, so they
  survive a restart with no re-delivery), the mount resolution both paths derive
  from the pin alone, and the apply. Injectable, so a test stands in for
  fetch + SRI-verify + layout + evaluate without publishing a package.
• CLOSURE_PACKAGE_DIR exists, threaded on the frozen substrate env, so the
  run child evaluates the pinned code and re-verifies its projection against
  DEFINITION_HASH — now the hub's approvedWireHash, never a sidecar
  recompute. A frame carrying no approved hash fails closed.
• The probe answers. createWorkflowProbeExecutor is wired at the boot edge,
  so workflow.probe.request returns a real inert projection, its advisory grant
  set, and its wire hash instead of workflow.probe.error.
• Child spawns are in-memory. createWorkflowSpawnChild /
  createWorkflowSpawnSuspendableChild are gone; a rung lifts its inline children
  to refs and serves grandchildren from that map, so no rung reads a definition
  off disk at any depth. An onTrigger body's sources.json is still staged (an
  in-process body child loses its env across a restart); its definition is not.
• The record carries the pin. referencedDefinitionHashes is gone;
  approvedWireHash and sourceRef are required, so an unrestorable record
  fails at the scan boundary rather than half-restoring.
• WORKFLOW_DEFINITION_REPO_ID/_REF are gone. What survives is
  WORKFLOW_DEFINITION_ID: identity for the run-authenticated capabilities route
  a step tool calls, never a repo to read from.

Vendoring

Four modules are near-verbatim copies of upstream's own sidecar at 4ed8baf4 —
the probe handler, the closure materializer, the closure apply, and the inline
source-asset delivery — plus bin/workflow-probe-child. VENDORED.md moves the
apps/sidecar row to that commit and records the two adaptations the fork's
module layout forced (host-platform resolution lives in this fork's
tool-materialization.ts; the probe child's shebang drops upstream's intx-src
condition, which workbench forbids).

Green

• bun run typecheck — exit 0, repo-wide
• apps/sidecar — 138 pass, 0 fail
• packages/folded-runs — 44 pass, 0 fail
• packages/chat — 509 pass, 0 fail
• bun run lint — 0 errors (14 pre-existing warnings)

Not proven — the honest part

No run has executed end to end on these rails. The task asked for a
RunStarted proof; it did not fit, because it needs a real published or
committed source package plus a live hub, and the box went to porting the
source-ref lane into a fork that never had it (upstream's sidecar at the prior
pin already had workflow-closure-apply, workflow-closure-materialization,
source-asset-delivery, and the probe handler; workbench's had none of them).

The remaining wire, in order:

1. The MCP credential-handle defect from step 2 still stands — mcp:<slug> is
   not a legal ToolCredentialHandle, so any MCP-pinned launch fails closed at
   render time. Gates a real chat launch, not the deploy path.
2. Nothing has driven a real renderAgentRuntimeSourceTree output through the
   deploy: every test injects the closure materializer, so the actual
   fetch/SRI/layout/evaluate path is exercised only by upstream's tests at the
   vendored pin.
3. The probe has never been driven by a hub. The executor is wired and
   typechecks; no workflow.probe.request frame has reached it.
4. The pinned tool-package arm was left in place deliberately. Upstream went
   all-source-tools (req.agent.toolFactories); workbench's agent-runtime pins
   tool packages instead, so materializeStepTools stays. Whether the
   source-format deploy still stages a tool-packages-manifest.json for those
   pins is the first thing an end-to-end run will answer.

Stacked on cl-6324-deployathead-convert.

[TheGreatAxios]

Landed via the stack tip: PR #108 (merge fbf0852) contains this branch's commits in full.