feat: ML-DSA-65, did:key, named hash algorithm, model provenance, log tiles and witnesses

- hashing.algorithm names the hash function in every document; a consumer refuses one it does not implement (doc.hash.algorithm)
- ML-DSA-65 (FIPS 204) is an implemented signature scheme: pure-Python reference in tools/oracle/mldsa.py checked against NIST ACVP vectors, a receipt signed by the new roster key dana, and signature vectors for key generation and a deterministic signature
- roster keys may carry a did:key, which the validator checks against the public key (doc.roster.did), and a witness purpose for parties that cosign log checkpoints
- model provenance: a correction's author and an annotation's generator name the model with provider, version and the hashes of its weights, prompt and parameters, and where it ran
- the transparency log gains the tlog-tiles static layout (fixtures/records/log/), a project settings.log with origin, witnesses and threshold, and an acceptance rule; the fixture checkpoint is cosigned by a witness
- store.sql: roster_keys accepts cose and ml-dsa-65 and gains a did column
- spec chapters 01, 08, 11, 18, 20 and 23, the rationale, glossary, fixture, vector and tool guides updated; stress harness covers ML-DSA

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

spec/08-fidelity.md

@@ -62,7 +62,7 @@ Its signing payload is the canonical JSON of `{"format": <the record's format>,
 | `gpg` | A detached, armored OpenPGP signature of the payload. |
 | `sigstore` | A Sigstore bundle for the payload, as JSON text. |
 | `cose` | Reserved: a COSE_Sign1 message over the payload, in Base64, as the IETF SCITT work shapes signed statements, so other transparency services can verify a receipt. No vector yet. |
-| `ml-dsa-65` | Reserved: an ML-DSA-65 signature (FIPS 204) of the payload, in Base64, for the time Ed25519 is no longer considered safe. No vector yet. |
+| `ml-dsa-65` | An ML-DSA-65 signature (FIPS 204, the pure variant with an empty context) of the payload, in Base64, for the decades after Ed25519 is no longer considered safe; the roster's `public` is the 1952-byte key in Base64. The reference implementation reproduces NIST's ACVP vectors; `signatures.jsonl` pins a key generation and a deterministic signature. |
 
 A consumer treats a record signed with a scheme it does not implement as invalid, so a reserved scheme can be adopted by a new minor version without any format changing.
 `signature.key` is the signer's roster key and equals `by`.
@@ -100,7 +100,8 @@ A spot-check is itself a receipt, so its status may depend on its own spot-check
 A revocation, `scienting-revocation/1`, names one `receipt`, or a `signer` and a `period` `{from, to}`, with a `reason`, and is signed like a receipt.
 It is valid when its signature verifies and its signer is the revoked receipt's signer, the signer it names, or a key whose `role` in the roster is `owner`.
 
-The roster, `scienting-roster/1`, lists the keys that may sign: each with an `id`, a `person`, a `role`, a `scheme`, its `public` key (Base64 for Ed25519), its `purposes` (`sign`, `spot-check`, `export`), `registered_at` and `revoked_at`.
+The roster, `scienting-roster/1`, lists the keys that may sign: each with an `id`, a `person`, a `role`, a `scheme`, its `public` key (Base64 for Ed25519 and ML-DSA-65), its `purposes` (`sign`, `spot-check`, `export`, or `witness` for a party that cosigns the team's log checkpoints, [23](23-log.md)), `registered_at` and `revoked_at`.
+A key MAY carry its `did`, the `did:key` decentralized identifier the public key determines: `z` and the base58btc of the multicodec prefix (`0xed` for Ed25519, `0x1207` for ML-DSA-65, as varints) followed by the key bytes; a validator refuses a `did` that the key does not determine (`doc.roster.did`), so a signer can be named outside the store without a second name.
 The `role` is the holder's role in the team that keeps the roster, `owner`, `editor`, `reader` or `guest`, as in a project ([20](20-projects.md)).
 Because the roster carries it, a package that carries its roster carries everything needed to judge its revocations.
 A package MAY carry the roster its receipts need as `roster.json`, so its receipts verify without the store.