Add meta_engine/lib/replay_proposals.js dry-run tool for gate/axis proposals

Create a new file exporting replay({ gateFn, sinceDate, lanes, limit }). Implementation: query hypotheses table WHERE lane IN (lanes || ['meta']) AND created_at >= sinceDate (default: 30 days back) ORDER BY id DESC LIMIT (limit || 50). For each row, JSON.parse the description field to get metaDesc, then invoke gateFn(row, metaDesc) which returns { matched: bool, reason?: string }. Aggregate into { total, matched_count, by_reason: {reason: count}, samples: { matched: first 5, unmatched: first 5 } }. Add CLI mode: 'node meta_engine/lib/replay_proposals.js --gate <relpath::exportName> --since 2026-05-01'. Every recent meta cycle has had ≥1 proposal whose falsifier says 'replay against last N rows' (2026-06-13 had 4 such, 2026-06-12 had 3). Without a shared tool, each proposer and architect implementer rewrites the loader logic.

Within 10 cycles post-build, ≥3 future proposals reference this tool path in their falsifier text instead of describing ad-hoc replay. Architect implementation work on any gate/axis proposal that already passes council saves ~30 min of duplicated loader code.

After 10 cycles, if 0 proposal falsifiers reference meta_engine/lib/replay_proposals.js OR runReplay, the tool exists but is not in the proposer's vocabulary — surface it in META_PROPOSER_SYSTEM as a follow-up. If 0 architect-implementation diffs use it in 60 days, it's a dead utility — remove.

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