Add validateProposal check: each non-new target_file must exist on disk

In validateProposal (line 137-172), after the existing target_files-is-non-empty-array check, add: const repoRoot = path.resolve(__dirname, '../..'); for each entry in p.target_files: if entry contains 'NEW:' prefix OR entry contains '/lib/' (heuristic for new-file TOOL/HARNESS proposals), skip; else if !fs.existsSync(path.join(repoRoot, entry)) return { ok: false, reason: 'target_file_not_found: ' + entry }. Rationale: the META_PROPOSER_SYSTEM constant itself references 'v2_a1..v2_a10 in filter_score.js' (line 27) but the live filter_score.js has 5 named filters (data_moat, ten_x_model_test, fast_feedback_loops, solo_founder_feasible, ai_providers_cant_eat_it) — i.e. the system prompt encodes a stale path/identifier reference. Same drift shape can leak into proposed target_files.

Replay against the last 30 meta proposals (~6 cycles): expect 0-2 to fail the gate (low rate, high signal — those are the ones that would not have implemented as written). Going forward, no council-advanced proposal can reach Architect with a typo'd or stale target path.

If >5/30 historical proposals fail the gate, the NEW-file detection heuristic is too narrow — broaden the allow-list patterns. If 0/30 fail and 0/30 fail over the following 60 days, no path drift exists in practice and the gate is dead code — remove.

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