test(cpg): confirm the session stays alive and halves query time (M2 11.4)

The leak was the whole cause. With the session closed by the transaction that owns
it, a session-enabled replay of the same pinned revisions under the same budget
keeps its session for the whole run: no session_query_failed appears on either
side, where the previous run reported one per side and fell back to the disposable
path for everything.

Measured on the same pins, instrument and budget, changing only the transport:

  vulnerable revision   326.4 s -> 243.3 s
  head query time        63.6 s ->  32.0 s
  base query time        85.1 s ->  51.2 s
  dominance and config   ~14 s each -> ~4 s each

Detections are unchanged: witness present, fixed twin analyzed and quiet, unchanged
revision not a regression, kill criterion not triggered. Speed bought by losing a
detection would not be speed.

This is a cold transaction on one teaching repository under a 900-second
development budget. It is not the hook latency gate, which is warm changed-code p95
against the frozen seven-class profile, and that is task 11.5. Rollout stays NO-GO.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01EmM1j46qgKMh3zqD1QMwEo

.kiro/specs/pre-push-safety-net/tasks.md

@@ -377,13 +377,14 @@ Preserve all completed task evidence below.
   - _Boundary: Cache and Engine Boundary, Push runner_
   - _Depends: 11.2_
   - _Requirements: 4.1, 4.3, 6.4, 7.3_
-- [ ] 11.4 Remove the startup cost from the critical path where the measurement says it pays
+- [x] 11.4 Remove the startup cost from the critical path where the measurement says it pays
   - With 11.3's stage costs in hand, decide what else to change. The candidates the M1b runs point at are the overlay pass, 15.8 s in a separate invocation, and session startup, 12.8 s, which may overlap the frontend build rather than follow it.
   - Change only what the measurement implicates, and keep each change's correctness evidence separate from its timing evidence. Do not substitute a faster census for a completed security check.
   - Done when the recorded stage costs after the change are compared against the same profile before it, with any regression in completed checks reported rather than traded away.
   - _Boundary: contributor-scan runtime_
   - _Depends: 11.3_
   - _Requirements: 4.1, 4.2, 6.2, 6.5_
+  - _Verified 2026-09-17:_ 1,399 tests passed, nine skipped; Ruff/format/mypy passed. The overlay, the last fixed cost bypassing the session, now runs in-session and the saved graph is verified rather than assumed. The first session-enabled replay then showed correct detections and no speedup, and a targeted probe disproved the sequence hypothesis before finding the real defect: a build runs on a copy of the backend, so the session it started was never closed, leaking a JVM holding the configured heap, twice per transaction, enough to exhaust the container. With that fixed the session stays alive for the whole transaction and no `session_query_failed` appears. Measured on the same pins and budget, the vulnerable revision went from 326.4 s to 243.3 s, head query time from 63.6 s to 32.0 s and base from 85.1 s to 51.2 s, with dominance and configuration each falling from about 14 s to about 4 s. Detections unchanged. Evidence: `benchmarks/measurements/2026-09-17-nodegoat-session-transport.json`.
 - [ ] 11.5 Rerun the frozen seven-class runtime profile and decide
   - Rerun the unchanged seven-class profile: identical-tip, function edit, dependency edit, configuration edit, cold, growth and multi-ref, three samples each, retaining every timeout and unresolved check. Identical-tip reuse cannot substitute for warm changed-code work.
   - Verify the M1 outcome still holds on the same three revisions through the production rules, so speed is not bought with a lost detection.