port: WITHDRAW 'the port draws a sweep the game does not' -- pteff03a IS drawn

Refuted by the Decoder (f6-unit11): the two strips are batched into a single
additive eight-vertex draw -- two quads -- and their log reader took the first
vertex match per draw line and discarded the rest. Every analysis saw quad A and
never quad B. No new capture was needed; pteff03a was in the same logs that were
read as declaring it absent.

Three of my claims fall with it, including one I put in a report to the human:
'the port draws two, the game's capture has one'. The port draws two and so does
the game. My census stands; it now AGREES with the capture instead of
contradicting it.

✅ Nothing in the port changed. I proposed gating pteff03a and held, because
absence in one capture read by one probe is a lead not a finding, and because the
check I asked for was a human's look rather than another measurement. That hold
is the only reason this cost nothing.

⚠️ The absence claim cited the port drawing pteff03a as evidence the PORT was
wrong -- a defect inferred in my renderer from a gap in a reader.

Recorded generally: an absence is a claim about an instrument, not the world. A
count of zero says only that nothing got through the reader. Every positive
result on the same capture is untouched because those compare like with like on
one quad; only the absence compared a count against zero.

docs/port/f6-what-starts-the-sweep.md

@@ -253,7 +253,30 @@ raise the residual rather than being absorbed, which is deliberate.
 
 ---
 
-# 🔴 Unit c — the port draws a sweep the game's capture does not, and I owe a correction
+# ❌ WITHDRAWN — Unit c: "the port draws a sweep the game does not"
+
+> 🔴 **This whole section is refuted, and the port was right.** `pteff03a` **is**
+> drawn by the game. The two strips are batched into a **single additive draw of
+> eight vertices — two quads** — and the Decoder's log reader took the first
+> vertex match per draw line and discarded the rest, so every analysis saw quad A
+> and never quad B. No new capture was needed; `pteff03a` was in the same logs
+> that were read as declaring it absent
+> (`docs/re/f6-unit11-pteff03a-IS-drawn.md`). Measured on both sides: the strips
+> travel in opposite directions with a size ratio of 1.301 against the declared
+> 800/600 = 1.333.
+>
+> ✅ **Nothing in the port changed on the strength of it.** I proposed gating
+> `pteff03a` and held, because absence in one capture read by one probe is a lead
+> and not a finding, and because the check I asked for was a human's look rather
+> than another measurement. That hold is the only reason this cost nothing.
+>
+> ⚠️ **And the absence claim cited the port as evidence against itself** — "the
+> port draws it, the game does not" — so a defect was inferred in my renderer
+> from a gap in a reader. Kept in place rather than deleted: the reasoning below
+> is sound given its premise, and the premise is exactly the kind that looks like
+> data.
+
+## The original section, kept for its shape
 
 ## First, the correction: my refutation was right in outcome and WRONG in its reason
 
@@ -292,8 +315,9 @@ t≈521, travelling **right-to-left** at 800 % vertical scale while `pteff03` ru
 left-to-right at 600 %. The capture covers that window and contains only
 `pteff03`.
 
-> **So the port appears to render a second light sweep, larger and travelling the
-> opposite way, that the game does not draw during the title build-in.**
+> ~~**So the port appears to render a second light sweep, larger and travelling
+> the opposite way, that the game does not draw during the title build-in.**~~
+> ❌ **False.** The game draws both, batched into one eight-vertex draw.
 
 ⚠️ **Absence in one capture is not absence in the game**, and this is one
 capture, read by one probe, identified by size. It is a lead, not a finding. But
@@ -444,3 +468,34 @@ a remote one.
 
 Whether the game's lights are one-per-trace or one glow spanning several — the
 human says they cannot tell, and it is the Decoder's screenshots to settle.
+
+
+---
+
+# 📌 What the withdrawal is worth, since the port lost nothing
+
+Three of my own claims rested on `pteff03a` being absent and all three fall with
+it: that the port renders a sweep the game does not, that this was "the first
+thing in F6 that is visible and port-side", and — in a report to the human — that
+"the port draws two, the game's capture has one." **The port draws two and so
+does the game.** The census on this page stands unchanged; what changed is that
+it now agrees with the capture rather than contradicting it.
+
+**The one thing that made this free was refusing to act on it.** The evidence was
+an exhaustive scan, from an agent with the oracle, corroborated by a mechanism
+and by two candidate causes. It was still an *absence*, measured once, by one
+reader — and the check I asked for was a human's look, not another measurement.
+
+⚠️ **An absence is a claim about an instrument, not about the world.** A count of
+zero says only that nothing got through the reader. Every positive result on that
+same capture — the alpha decomposition, the press-vs-control comparisons, the
+pulse ratio — is untouched, because those compare like with like on the same
+quad. Only the absence compared a count against zero, and that is precisely where
+a truncating reader is fatal.
+
+📌 The Decoder notes this is the third time this corpus has been bitten by an
+under-reading dump, and that `REFUTED.md` already recorded a draw carrying two
+rotated parallelograms — **the general fact was written down before the reader
+contradicted it.** Their cheap check is worth repeating here because it applies to
+anything the port ever reads: *read one raw record in full before trusting any
+count derived from it.* The batch size was printed on every one of those lines.