feat(ppd): a second verification arm that needs no live upstream

[paulieb89]

Why

Stage 1's live arm has failed twice — 429 on 2026-09-02, then a 503 after
271.8s on 2026-09-04. Its central criterion is the false empty:

"snapshot_false_empty": snap.count == 0 and live.count > 0

One arm cannot detect that, because a wrongly-empty answer is indistinguishable
from a correctly-empty one. The 2026-08-28 snapshot-only rehearsal passed 85
assertions across 13 cases and still couldn't close the gap — and no number of
further snapshot-only assertions would.

This adds a second arm that is not the live source: the artifact compared
against itself, read a different way. No network, no HMLR dependency.

Why it can find anything

The schema stores outcode/sector as materialized columns. That removes
the STRSTARTS("B5")-matches-B50 bug class entirely — but relocates the
risk: if the build wrote those columns wrongly, every geography query is
silently short, and querying the same column can never reveal it.

The two derivations are genuinely independent:

build (build.py _DERIVE)	split_part(trim(postcode), ' ', 1) — validates nothing, never uppercases
reference (postcode_rules)	validated regex grammar, GIR-exact, uppercases, rejects malformed

A postcode they disagree on is a row the adapter cannot reach by geography.
That's a false empty, discoverable offline.

The checks

1. Geography derivation — recompute from postcode, compare to what the
   build stored. Three outcomes kept apart because their causes differ:
   unreachable, case_mismatch (build never uppercases, query side does),
   unvalidated.
2. Query semantics — every predicate, the ordering and the limit
   reimplemented in plain Python, filtering on geography recomputed rather
   than the stored column, so a wrong derivation can't hide by being wrong
   identically in both arms.
3. Partition completeness — a missing year returns fewer rows rather than
   failing.

Result against the real artifact

rows_examined  10,394,935   (every row, not a sample)
passed         true
findings       []
elapsed        90s

Ran alongside production traffic without disturbing it: MemAvailable
1,599,652 kB after vs 1,596,868 kB before, health 200 in 49–97ms
throughout, Fly check passing.

Memory safety is load-bearing here

My first draft used fetchall() and accumulated one id per disagreement.
Against 10.4M rows with ~1.6 GB free on a Machine serving production traffic,
that would have OOM-killed the live app — and the id-accumulation would have
failed hardest exactly when the artifact was most broken. Both were fixed
before the tool was pointed at the real artifact. Rows now stream in 50k
chunks; findings carry counters plus a capped sample. Pinned by tests, including
a cursor stand-in whose fetchall() raises.

Tests

31 tests. Every check is driven from a row built to carry its specific
defect and asserted to be found, then a clean row asserted to pass — a
verifier that only ever passes is worthless.

./scripts/validate.sh → 2042 passed, 27 skipped.

Scope limits, stated

• Not Stage 1. The report sets not_stage_1_evidence: true. It shares the
  snapshot's own data, so a row that never reached the artifact stays
  undetectable. Only an independent publication can close that — the live
  source, or the 5.5 GB bulk CSV whose download ppd-snapshot-build.md records
  as not authorised.
• cases_compared: 0. The CLI runs checks 1 and 3; the per-corpus-case
  comparison is implemented and unit-tested (python_select) but not yet wired
  to the adapter and frozen corpus. The report states 0 rather than implying
  coverage it lacks.
• No latency measured; nothing about agreement with HMLR today.

What it does establish: the artifact is internally consistent, and the query
path can reach every row it contains.

Out-of-band operator tooling on the same contract as boot_only_verify.py —
never imported by the app, never wired into CMD, inert unless invoked. Not
added to the image in this PR; it was run by copying the single file in.