docs(specs): define the attestation format and handle normalization

[xgreenx]

Stacked on #11. Review that one first — this diff shows only what it adds on top.

Two places in the suite named a thing without saying what it is. This gives each a concrete definition an implementer can build from. It changes no decision already made; #11 carries the corrections.

Common §9.1 — attestation format

The attested data becomes a byte concatenation, and the signature is over it. The split that makes the field list load-bearing: the Notary Service signs off chain, where it holds the transcript, and verifies on chain, where it holds none. So verification derives the key from the attested-data-and-signature pair alone and answers whether that key is currently trusted. A caller-supplied digest, preimage hash, or verification key is refused — a caller-computed digest authenticates whatever the caller hashed, not the bytes the Platform Verifier goes on to read.

The layout carries formatTag, platformId, operationTag, authorityId, createdAt, the two transcript lengths REQ-COMMON-36 requires, and per direction a list of revealed ranges with their offsets and a list of range commitments with theirs.

What it deliberately does not carry:

• No Chain ID, no verifier identity. The attested data describes a session, not a destination. The Authorization Digest already commits the chain and is bound to the token attestation through the revealed code_verifier, so replaying on another chain takes a preimage. Binding to a verifier identity would be worse than redundant: a newly registered Platform Verifier version could not check attestations made before it existed.
• No handle, account identifier, client identifier, or chain address. Each is already derivable from the revealed ranges, a second signed representation can disagree with the bytes it was taken from, and producing one would make the notary decide something profile-specific.

Platform §2.1a — handle normalization

The criteria prose becomes the algorithm: five per-platform parameters, six ordered steps, four rejection kinds. The published vector table becomes a cross-check on an implementation of that algorithm rather than its source — so a disagreement between a vector and the algorithm is a defect in the vector table.

Notes

• New IDs: REQ-COMMON-47..61, REQ-PLAT-61..74, TEST-COMMON-24..26. docs(specs): on-chain verification path, two-attestation circuits, notary fee #11 takes REQ-COMMON-41..46, REQ-PLAT-54..60, TEST-COMMON-20..23, so each branch is contiguous on its own.
• Linter: 0 errors, 0 warnings.
• Where docs(specs): on-chain verification path, two-attestation circuits, notary fee #11 requires a signed transcript length without naming a field, this PR names sentTranscriptLength and recvTranscriptLength; where docs(specs): on-chain verification path, two-attestation circuits, notary fee #11 says the verifier compares the attested authority, this PR names authorityId.