fix: refute (ar)'s intake finding; fix the D20 gloss class; add X-Robots-Tag on *.pdf

Pouya's rulings of 2026-09-03, in five parts.

1. THE INTAKE FORM IS NOT BROKEN. (ar) was wrong. docs/09 §7.1 verbatim —
POST /api/intake with an Origin header — returns 303 to /contact/could-not-send/
with access-control-allow-origin echoed; the same probe without Origin returns
403. A bare POST 403s BY DESIGN and §7.1 says so three lines below the probe it
prescribes: "403 means the Origin header did not arrive". The earlier finding
read a status code without reading the document that defines it. Second time in
two days. CLAUDE.md's instrument list goes eight to nine. D20 findings 12 and 19
fall with it; §7.2 (that both emails arrive) is still owed.

The correction is APPENDED as entry (as); (ar) stands unedited.

2. The privacy retention comment was stale, not a defect — superseded by his
decision to publish and confirm after launch, reading from 2026-09-04. Reworded;
the TODO(pouya) came off with the gate it enforced. The mechanism finding
survives: it was a JSX comment, stripped by Astro, so no build or deploy path
could see it. A publication gate that lives only in a stripped comment is not a
gate. §9 Q60 corrected.

3. The gloss class is fixed — 15 of the 20 D20 findings, 14 distinct edits across
9 files, under the rule "the gloss may say no more than the extract says; no new
claims, no new sources". Swept three unpublished insights drafts too, and
corrected the wrong CAA attribution at its source in docs/reference/, which is
where a fixed page re-seeds. /bio/ changed, so the committed PDF is regenerated
(89,549 B, 1 page asserted). Three findings outstanding: 10 needs a ruling, 11 is
ruled and owed via Q60, 13 needs him to have said it. R1 is not one of the twenty.

4. X-Robots-Tag cannot be done with S3 object metadata — --metadata writes user
metadata, returned as x-amz-meta-x-robots-tag, which no crawler reads. Built as
the CloudFront response-headers policy docs/06 has specified all along:
configure.mjs section 4. It needs a --apply run, not a deploy. The policy is
cloned from whatever is attached at run time and reconciled on every run, because
a response-headers policy replaces rather than merges.

5. Headshot deferred as an open non-defect. The master and the srcset ladder are
both fine; Astro passes no quality, so AVIF encodes at sharp's default 50 and is
served first.

Two review rounds, 29 findings, all resolved, none declined; stopped at two per
D19. NINE of round 2's fourteen were defects in round 1's own repairs — including
a fix that harmonised both /fees/ rows onto wording that was itself unregistered,
publishing an unsourced fee term twice where it had been once.

Gates, exit status read for each: check 0 (0 errors, 0 warnings, 0 hints),
build 0 (23 pages), check:claims 0, check:intake 0, og:proof 0, lint 0, minifier
grep exit 1, router.test.mjs 30/30. Lighthouse NOT run. Nothing deployed and
nothing applied to the distribution.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5

docs/01-architecture.md

@@ -497,9 +497,17 @@ position, not a claim of existing volume.**
 > occurrences of "allocation" of any kind across the connection process. It also
 > reached `src/data/site.ts` and shipped in the six-card grid on three pages.
 >
-> **Use the terms these bodies use:** *connection assessment and approval (CAA)*
-> is the umbrella; the IESO performs a *System Impact Assessment (SIA)* and the
-> transmitter a *Customer Impact Assessment (CIA)*. **Ontario has no
+> **Use the terms these bodies use:** the IESO's own words are *"the IESO's and
+> transmitter's connection assessment and approval (CAA) process"*, within which
+> the IESO performs a *System Impact Assessment (SIA)* and the transmitter a
+> *Customer Impact Assessment (CIA)*. ⚠️ **This read "CAA is the umbrella" until
+> 2026-09-03** — which is the extract's own COMMENTARY, not the IESO's, and
+> `CLAUDE.md` is explicit that commentary around a quotation is this
+> repository's voice. The pages took the attribution from here and gave the
+> process to the IESO alone. **And it is the CONNECTION PROCESS that runs to
+> *up to* six stages, not the CAA** — the source scopes the count by connection
+> type, and CAA is stage 2 of that process rather than a name for it. Naming the
+> wrong subject here is how the conflation reaches a page. **Ontario has no
 > interconnection queue** — the IESO says so in terms and works from "committed
 > projects" instead, so "our place in the queue" describes nothing. The
 > genuinely adjacent term, the OEB's *Capacity Allocation Model* in the
@@ -530,9 +538,10 @@ position, not a claim of existing volume.**
 > - **LAT Rule 2.4:** *"'Case Conference' has the same meaning as 'Pre-Hearing
 >   Conference' as defined in the SPPA."* **"Pre-hearing" is the Tribunal's own
 >   label**, and what it labels is a case conference.
-> - **Rule 14.3:** a **Member** presides and is then disqualified from the
->   hearing panel; **Rule 14.6:** parties must attend. The neutral is the
->   Tribunal's. A privately retained one is not appointed to it and cannot be.
+> - **Rule 14.3:** a **Member** presides and does not then sit on the hearing
+>   panel except with the consent of the parties; **Rule 14.6:** parties must
+>   attend. The neutral is the Tribunal's. A privately retained one is not
+>   appointed to it and cannot be.
 > - The LAT Rules contain **zero** occurrences of `mediat` or `arbitrat` —
 >   0 in 66,593 characters. The concept is not in them.
 > - The LAT-AABS page itself, though, says: *"Before you apply to the LAT-AABS,