Create hypothesis_engine/tools/orphan_scanner.js diagnostic script

Create new standalone Node.js script. Opens engine.db with better-sqlite3 {readonly: true}. Runs: SELECT id, phase, source, created_at FROM hypotheses WHERE phase NOT IN ('killed','graduated','exhausted') AND kill_reason IS NULL AND (source LIKE '%backfill%' OR source LIKE '%S148%') AND v2_a1 IS NULL. For each matching row, counts associated moves: SELECT move_type, COUNT(*) FROM moves WHERE hypothesis_id=? AND move_type IN ('evidence_search','red_team_kill','steelman') GROUP BY move_type. Outputs JSON to stdout: {orphan_count, total_moves_wasted, rows: [{id, phase, source, created_at, move_breakdown}], recommended_kill_criteria: '<exact SQL WHERE clause reproducible as a gate>'}. Invocation: node hypothesis_engine/tools/orphan_scanner.js. No writes, no side effects. Requires no new dependencies (better-sqlite3 already in use).

Report reveals exact count of live orphaned rows (expected >0 given 7 kills in 7-day window with kill_reason='v2_backfill_orphan_S148'). Provides move_waste count per orphan to quantify GATE proposal value before implementation. If orphan_count=0, the GATE proposal (P1) is moot — saves 4 hours of engineering. If orphan_count>20, the move waste is larger than the 7-kill sample implies and gate priority increases.

If orphan_scanner reports orphan_count=0 but the kill log shows v2_backfill_orphan_S148 kills appearing in the subsequent 7-day window, the discriminating columns are not source/v2_a1. Cross-check by querying the actual killed rows' source and column values to identify the true distinguishing predicate.

Rejected at the council verdict. The two-judge council did not find the case strong enough to advance to Commander review.