Correct the DCP4 record: overlap relabel, C4 attribution withdrawal, owner-exchange scope change

[FujitsuPolycom]

What and why

Follow-up to #265/#269 — three corrections to performance/records/glm53-flash/r33-image020-tp4-dcp4-sparkcache-20260911.md, per review:

1. Overlap relabel. The DeepSeek V4.1 distribution jobs (host-level deepseek-distribution-fabric.service, journal-verified: r0 13:09:30–13:42:50, r1 13:09:34–13:42:22, r3 13:09:35–13:42:20 Central; r2 none) overlapped the first measurement pass (37K probes, prefill medians, C1/C4 decode windows ≈ 13:28–13:39). Those windows are now labeled potentially affected; the RouteFinal/nocache/final passes (13:39+) are after the jobs ended. The earlier 'no rerun required' claim is withdrawn: a rerun was attempted but the ring cannot currently restart after the 15:22:14 multi-rank stop event (documented in Conditions with the diagnosis evidence).
2. C4 attribution withdrawn. The full-CKV gather is prefill-only (num_decode_tokens == 0 in its gate) and cannot explain a decode-window gap. No attribution is now claimed without profiling evidence.
3. Owner-exchange scope change recorded. The image implements DCP4 top-k ownership arithmetically over the all-gathered cache; there is no separate exchange primitive. The record now states explicitly that the amended implementation does not automatically satisfy Add and live-qualify a TP4/DCP4 launch profile on the R33 image #264's original owner-exchange acceptance item — it is marked amended, not passed.

publication.json record hash repinned.

Validation

• pytest runtime/sparkring/jovian-r33/image/test_r33_image_contract.py runtime/sparkring/jovian-r33/profiles/test_profile_contract.py: 67 passed locally
• Record hash matches the publication.json pin