docs(site): the landing page teaches the signature v1.4.0 rejects — flip it with the release, not before

[pviti]

Severity: Low. A release-checklist item, not a defect today. From the 2026-08-25 contract read-through.

docs/index.html:191 and docs/index.html:325 both tell the buyer they sign an EIP-3009 TransferWithAuthorization. That is correct for the deployed v1.3.0 and wrong the moment v1.4.0 (#64) is activated: #35's fix makes every call site the receive variant, and the two typehashes are distinct (interfaces/IEIP3009.sol:25-34).

The timing is the whole point. Fixing it now would make the public site describe a signature the live deployment rejects — the same failure in the other direction. This belongs in the v1.4.0 rollout, not before it.

Failure scenario if it is missed: after activation the landing page is the most discoverable rail0 documentation there is, and it names the one typehash that reverts at the token. An integrator who trusts it wires a signer that fails on every payment, with nothing in the error pointing back at the page.

Suggested fix: add to the v1.4.0 release checklist (#64) — flip both TransferWithAuthorization mentions in docs/index.html to ReceiveWithAuthorization, in the same change that moves the site's version. The site already needed a version correction once (#42), so the checklist is the right place for this class of thing rather than a separate pass.

Worth considering while in there: whether the site should name the variant at all. It is a detail that has now rotted twice, and "the buyer signs an EIP-3009 authorization" carries the same meaning to the audience the landing page is written for. The precise typehash matters to integrators, who belong in the README.

[pviti]

Already fixed — in #74, riding the release

Both mentions are flipped to ReceiveWithAuthorization on docs/receive-authorization-and-site (#74, draft, base v1.4.0): docs/index.html:191 and :325.

The timing this issue insisted on is handled by the base branch rather than by a checklist step anyone has to remember. Pages serves main:/docs — verified via the API: source branch main, path /docs, CNAME rail0.xyz — so a change sitting on v1.4.0 goes live at exactly the moment the release merges, and not a moment earlier. There is no window in which rail0.xyz describes a signature the live deployment rejects, in either direction.

One bookkeeping trap this would otherwise have hit

#74 cannot close this issue. A PR merging into v1.4.0 creates no closing links at all — GitHub only does that for PRs targeting the default branch — and #74's closingIssuesReferences was empty despite its body saying "closes #69". The keyword now also lives on the release PR #64, which does target main, so this closes when 1.4.0 ships.

Deliberately still open, and not part of #74

Whether the landing page should name a typehash at all. It has now rotted twice, and "the buyer signs an EIP-3009 authorization" carries the same meaning to the audience a landing page is written for — the precise typehash matters to integrators, and they are reading the README. That is an editorial call about the site's voice rather than a fix, so it had no place in a release PR. If the answer turns out to be "don't name it", this is where that change belongs.