feat(ppd): route subject-property history to the snapshot

[paulieb89]

Why

_subject_property_lookup called the live client directly, bypassing routing.
The reason was real — an 11-year snapshot would truncate a property's history,
and a truncated history is indistinguishable from a complete one. Coverage now
runs from 1995, so the reason is gone, and leaving it live left the feature
broken whenever the live source was.

The risk was the matching, not the routing

Live filters paon/street with CONTAINS(LCASE(...)) — substring. The
uniqueness guard downstream exists because that is over-broad. An
exact-equality snapshot filter would look like a tightening while silently
changing behaviour: the guard would stop firing and vague input would resolve to
one property instead of being refused.

Measured against DuckDB 1.5.5 before writing the filter:

contains(lower(paon), lower('27'))  -> ['127','27','27A']   like live
contains(...) with '%'              -> []            literal
LIKE      with '%'                  -> everything     wildcard

Hence parameterised contains(), never a LIKE built from caller text —
paon='%' would otherwise return every row on the street. Pinned by test.

Filters are pushed into SQL, not applied after, or the limit + 1 completeness
basis stops meaning anything: a short page must prove the source was
exhausted, not that our own post-filter discarded most of it.

Routing

Follows _fetch_comps exactly — try the adapter, catch SnapshotFailure, append
fallback_warning, fall through to live. GUARANTEED rather than EXPLICIT,
because this query names no dates and the honest answer to "the whole history"
is the whole coverage plus a warning, not a refusal.

SubjectProperty keeps its own provenance block even now both halves are
snapshot-sourced: the sample limits and completeness bases still differ, so one
label over both would misstate one of them.

Two existing tests changed — in setup, not in what they assert

• test_mixed_source_comps_declares_both asserted the subject half is SPARQL.
  That split is what this removes; renamed, inverted, and it now also asserts the
  two provenance blocks remain distinct objects.
• test_subject_property_failure_warns_and_success_does_not induced both
  conditions through fake_live, which the lookup no longer calls. Absence is
  now an address the snapshot doesn't hold; failure is the snapshot query
  raising, targeted at the subject query alone. The assertions are unchanged
  — absence is silent, failure warns, neither is ever the other.

A pre-existing defect this surfaced — not introduced here

Verifying against the real artifact, 5 Alexandra Road still returns None:
DE12 6LL contains a 15 Alexandra Road, contains("5") matches it, and the
guard correctly refuses rather than guessing.

Measured across six outcodes: 14% of addresses (1 in 7) are unresolvable
this way — 5/15, 1/11/21, 7/17.

This PR does not change that rate. The live source always had full history
back to 1995, so it always saw 15 Alexandra Road and always collided.
Identical before and after; this work merely made it visible.

Worth fixing separately, and the fix is small: prefer an exact paon match
when one exists among the candidates. In every case of this class the exact
match is present — that's why it collided — so it resolves the whole 14%
without weakening the refusal-to-guess principle.

./scripts/validate.sh → 2208 passed, 28 skipped.