PUF stage manifest declares a support_clip op that no execution path honors (dead donor_realized contract)

Found during the #462 fix-3b diagnostic. The PUF stage manifest declares

{"kind": "support_clip", "range": "donor_realized"}

(source_stages.json:111-114) but the declaration is dead twice over:

1. Bypassed: the production builder reads the PUF HDF5 and calls the QRF chain directly (build_us_puf_support_base.py:981-989, :1811-1829); nothing routes this stage's ops through the generic runtime.
2. Mis-shaped: the generic support_clip handler accepts output + numeric lower/upper and does not implement "range": "donor_realized" (us_runtime/source_runtime.py:1050-1083) — so even a routed invocation would fail.

Also: even as intended, a donor-realized min/max clip would not have prevented the #462 tail defect ($594,483.64 is an observed donor value, well under the $5.96M donor max).

Same disease class as the never-invoked capital_gain_distributions stage fixed in #480: a declared operation that no execution path honors. Options: implement donor_realized in the handler AND route the stage through it, or delete the declaration and let the #462 per-target weighted-quantile bound (which subsumes the useful part of the intent, with real tail semantics) be the recorded contract. Either way the manifest must stop declaring machinery that never runs — a spec-validation guard of the #477 no-hardcoded-counts kind would prevent the class recurring.

Relates #462, #480.

Read source_stages.json:111-114 alongside build_us_puf_support_base.py:981-989 and :1811-1829, then inspect us_runtime/source_runtime.py:1050-1083 to confirm the declared operation has no honored execution path. Resolve whether to route and implement donor_realized or remove the declaration, and add the proposed spec-validation coverage. Done means the manifest no longer declares machinery that execution cannot honor.