JIT executor Phase 3: SwiftUI session-lifecycle integration + hot-reload

[obj-p]

Wire the custom JIT executor into PreviewsMCP's session lifecycle (design prompts/jit-executor-design.md §8 Phase 3). Builds on Phase 1 (#183 via #185) and Phase 2 (out-of-process executor, #186).

Goal

The FileWatcher + Compiler + SessionResolver pipeline routes structural edits to JIT-link instead of thunk-rebuild; literal-only edits stay on the thunk/DesignTimeStore path. Run a real SwiftUI View body in the agent and drive edits without a full daemon restart.

Key decision: respawn-first

Updates use the agent-respawn model, not in-place write_mem patching:

• The Swift runtime has no deregister for __swift5_proto/__swift5_types (Phase 1 SP0d-D), so a long-lived agent leaks metadata registrations on every edit. Respawn is the clean teardown.
• This matches the W3 empirical finding (Apple respawns for every edit kind tested; zero write_mem).
• Preserving runtime @State across a structural edit is not a Phase 3 goal (acceptance is latency-only). Literal-state continuity is kept via re-seeding DesignTimeStore after respawn.

The §5/§6 in-place patch + Begin/End/cancelUpdate handshake is kept as a later, clearly-scoped chunk, added only if it earns its keep.

Chunks

• P3.1 — Agent SwiftUI render harness. (a) instantiate a real View body in the agent; (b) render it offscreen to a bitmap.
• P3.2 — Hot update via respawn: edit → recompile → respawn agent → new render.
• P3.3 — (conditional) Begin/End/cancelUpdate handshake (§5/§6).
• P3.4 — Daemon integration: route structural edits to the JIT path; literal-only stays on DesignTimeStore. Pulls in the deferred SP5 (SessionResolver/JIT API).
• P3.5 — docs/jit-executor-phase3-plan.md + PR + CI green.

Plan doc tracked in docs/jit-executor-phase3-plan.md.