Kinetic witness run 2: popup birth kills the App Worker (vessel heap-join defect)

Context

The merged kinetic witness (#15644, FleetCockpitKineticNL.spec.mjs) asserts a two-run determinism contract that is deterministically false on current dev: run 1 completes drill → pop-out → glide → reattach cleanly; run 2's pop-out birth kills the freshly-booted App Worker (Target App [<id>] not found, ConnectionService.resolveRequest). Emmy's 2/2 headed repro at 8685aa01aa, my 4/4 headed repros across dev states (ports 8128/8129/8130).

Live latest-open sweep: checked latest 20 open issues at 2026-07-21 ~21:45Z; no equivalent found. A2A in-flight claim sweep (last 60 min): no competing claim — Emmy assigned this repair to me via A2A task; I am claiming it and filing this diagnostic record.

The Evidence Chain

• Headed fails, headless passes — the defect needs real OS windows.
• The kill is the run-2 popup's birth: windowOpen fires, the child window opens (about:blank, per operator live observation: new title, no navigation), and the freshly-connected App Worker disconnects ~1.3s after boot — orderly 80-byte disconnect, no page crash, no console error, no third navigation (verified via framenavigated tracing).
• Not a double-navigation race: dropping the between-runs page.reload() (single goto per run) fails identically.
• Pre-existing, not a today regression: fails identically at c201de8bcb~1 (dev from 2026-07-19, before #15617/#15629/#15633/#15638/#15644). #15644 itself is spec-only; the spec's two-run structure merely exposes the defect.
• The child's boot stalls at about:blank (operator's live read) — consistent with the SharedWorker/App Worker dying mid-join, leaving the vessel window without its heap authority.
• Bridge timeline (headed, port 8128): run-2 worker connects → answers baseline get_instance_properties calls → run-2 windowOpen → worker disconnects → resolveRequest → "Target App not found".

Hypotheses Ranked (falsification guidance)

1. SharedWorker heap-join on second pop-out within one browser context — the child joining the freshly-restarted SharedWorker kills it (registration collision or re-entrant boot on the vessel registry). The shared-window name fm-agent-detail-neo-fm-fleet-cockpit-1 is identical across runs; the main-thread openWindows entry IS cleaned on close (src/Main.mjs:847), but the SharedWorker-side registration lifecycle for closed vessels was not yet audited (start: Neo.Main windowOpen/native-route handshake src/Main.mjs:959-1035, WorkerManager window registry).
2. Child-app boot exception inside the SharedWorker — the widget childapp's boot crashing the shared process only when the parent's prior vessel lifecycle ran once before.
3. A teardown ordering defect in the reattach path — run-1's close leaves the heap in a state where the next vessel's join is fatal.

Acceptance Criteria

• Root cause identified and repaired (product side — the spec is a witness, not the defect)
• FleetCockpitKineticNL passes --headed twice consecutively on one port (the determinism AC as written)
• The run-2 popup navigates (no about:blank vessel state)

Out of Scope (today's film path)

Emmy's Build Week capture uses one clean loop (run 1), which is green — the film is unblocked while this repair lands.

Related

• #15644 (the merged witness exposing this), #15631 (the kinetic demo ticket), #15648 (detail vessel boot connect-window — likely the same machinery)

Origin Session ID: d8a51237-4fcc-4171-8071-a391da0be361

Retrieval Hint: "kinetic run 2 popup App Worker disconnect Target App not found about:blank vessel"

Truth-fold at close (2026-07-24, @neo-opus-vega — per PR #15814 review cycle 1, RA2)

The diagnosis falsified this ticket's premise parenthetical: the root cause is not product-side — the vessel/heap-join machinery is exonerated (SharedWorker registration tables pristine at run-2; the App SharedWorker does not even survive the between-runs reload boundary). The defect was the e2e launch configuration: --use-gl=desktop (allowlist-rejected on modern Chrome → gl=none,angle=none) plus --disable-software-rasterizer let Chromium's GPU-crash threshold terminate the entire headed browser at run-2's popup birth. Full receipts: https://github.com/neomjs/neo/issues/15664#issuecomment-5069969520

AC dispositions (delivered by PR #15814):

• AC1 "Root cause identified and repaired (product side — the spec is a witness, not the defect)" → delivered with the parenthetical corrected: root cause identified and repaired — in the launch config, not product code. The spec IS a witness; the witness's environment was the defect.
• AC2 "FleetCockpitKineticNL passes --headed twice consecutively on one port" → delivered: 2× headed green on the affected seat post-fix (pre-fix: 4/4 deterministic kill).
• AC3 "The run-2 popup navigates (no about:blank vessel state)" → delivered: run-2 popup navigates and joins; identical beat logs both runs.

Measured backend with the fixed flag set (this seat, headed AND headless): ANGLE (Apple, ANGLE Metal Renderer: Apple M5 Max).