re: shape the F6 out-of-sample residue (issue #9) -- one open question, not three

f6-out-of-sample-RESULT.md left three failures unexplained beyond "n=2 wasn't
enough". Reviewing what's already decoded: two of the three (the ptcopyright/
parent ramp ratio, the sweep-leads-plate lead) fail in the SAME direction
(0.75x, 0.71x of predicted), and f6-unit10 already established the sweep and
plate families are gated by separately-triggered parents -- a ratio across
two independently-triggered elements has no structural guarantee of being a
constant, unlike a ratio internal to one element family (which is exactly
what the passing three checks are). The gross mislabeling that caused the
ORIGINAL 1.7x conflict was fixed two days before the prereg was written, so
that's ruled out as the cause here; whether the cross-group phase genuinely
varies boot to boot vs. an artifact in the frame-based ratio math is still
open, and needs more captures to tell apart -- filed as a follow-on, not run
here.

check_labels.py conflated two different claims under one "N LABEL(S) DRIFTED"
verdict: identity checks (which element -- clock-free, still 3-for-3 out of
sample) and timing checks (a cross-element ratio and a self-consistency curve
fit -- 0-for-2 out of sample). Split into two reported groups; only identity
gates the exit code now. Tolerances untouched -- widening them to pass f6c
would be tuning the check on the case that failed it, the same error class
already named twice in this corpus. Verified with synthetic data shaped like
the real f6c residue (3/3 identity, 0/2 timing, exit 0) and confirmed the
selftest's injected mislabel still fails an identity check (exit 1) --  no
capture exists in this fresh container to run it against real logs.

The withdrawn sweep->plate lead (0.138-0.141) stays withdrawn. Nothing here
reinstates a number.

docs/port/HANDOFF.md

@@ -6478,3 +6478,48 @@ drop it.
 capture-only labels, **fails its first independent test**: I validated it on the
 two captures that produced the labels. Two of four checks fire on a third. Treat
 it as unproven, not as a check.
+
+## 🟡 Shaping the residue above (issue #9) — the sweep→plate lead stays withdrawn; nothing new to author
+
+[`docs/re/f6-residue-shaping.md`](../re/f6-residue-shaping.md). No new number
+for you here — this is a static review of the three failures above, and the
+withdrawal stands exactly as it was.
+
+**What's new:** the three failures aren't three independent misses. Two of
+them (the `ptcopyright`/parent ramp ratio, the sweep-leads-plate lead) both
+miss **in the same direction** (0.75×, 0.71× of predicted), and the corpus
+already has a decoded reason they might: `ui-layout`'s own
+[`f6-unit10`](../re/f6-unit10-parent-alpha-gates-the-sweep.md) says the sweep
+is gated by its own parent's alpha, "not by anything to do with the plate" —
+i.e. the sweep-family and plate-family clocks are **declared as separately
+triggered**. A ratio between two independently-triggered elements' timings
+is not guaranteed constant just because each element's own animation is. The
+third failure (the pulse's own amplitude curve fit) is a different, narrower
+thing — a single element's self-consistency check, not a cross-element one —
+and is not explained by the same argument.
+
+⚠️ **This is a hypothesis the existing write-up points at, not a new
+measurement.** The gross mislabeling that caused the *original* 1.7× conflict
+was fixed two days before the out-of-sample prereg was written
+([`f6-plate-identity-and-clock-conflict-resolved.md`](../re/f6-plate-identity-and-clock-conflict-resolved.md)),
+so that specific bug is ruled out as the cause of *this* residue — but
+whether the cross-group phase genuinely varies boot to boot, versus an
+artifact in how the checker derives ratios from raw frame numbers, is still
+open. **Nothing here reinstates the withdrawn 0.138–0.141 lead.**
+
+**`check_labels.py` repaired, not patched.** It now reports two groups:
+*identity* checks (which element you're looking at — clock-free, 3-for-3
+including `f6c`) gate the exit code; *timing* checks (a cross-element ratio
+and a self-consistency curve fit — 0-for-2 on `f6c`) print in full but no
+longer read as a label failure. Tolerances are untouched — widening them to
+pass `f6c` would be tuning the check on the case that failed it. Verified
+with synthetic data shaped like the real `f6c` residue (3/3 identity pass,
+0/2 timing fail, exit 0) and with the selftest's injected mislabel confirmed
+to still fail an *identity* check (exit 1) — no capture available in this
+container to run it against real logs.
+
+**Follow-on filed, not started:** three more independent no-input boots with
+`check_labels.py`'s per-run diagnostics saved, to see whether the timing
+residue clusters (points at a real boot-order dependency) or scatters (points
+at instrument sensitivity). `state/proposed` — new exploratory dynamic RE,
+not a continuation of this shaping pass.