Add G-0002: raw checksum, the first capability claim (+ the 3-store cluster profile)

[eduralph]

Stacked on #5 (the roadmap/rules docs). Merge #5 first; this branch will be retargeted/rebased onto main after — same squash-merge geometry as before.

What & why

The first roadmap-execution slice (roadmap §5.6 + §8 prerequisites 0 and 1): the parity ledger's first capability claim — raw checksum exists in client-go and not in client-rust — plus the 3-store cluster profile the replica/stale-read scenarios (§5.4) will need.

• Protocol: open_raw_client / raw_put / raw_checksum commands in parity-proto and both drivers; a ChecksumObs evidence field on Observation — recorded, never projected (crc64/total_bytes cover prefix-included key bytes, so they legitimately differ between the two runs of one comparison).
• The claim: scenarios/raw-checksum.json + ledger G-0002 (kind = "capability", expect = "diverges"): oracle answers ok with server-side crc64 evidence (total_kvs: 3 matching the three seeded pairs); the subject answers unsupported — the driver does not emulate the feature. Declared field-complete (class + unsupported.detail) from the observed divergence report. The day client-rust gains the request, XCONVERGE fires and G-0002 is re-stated as a regression guard.
• Cluster: cluster/docker-compose-3store.yml + pd-3store.toml (max-replicas 3) + make cluster-up-3store; wait-ready.sh grows an expected-store-count argument. Boot-verified: three stores Up. Mutually exclusive with the single-node profile (same host ports), documented as such.
• Template/docs: PR-template categories updated to the repo's actual shape; roadmap §5.6/§8 and rules RAW-4 flipped from prospective to landed.

Kind of change

• Gate/harness code (crates/, go/)
• Scenario / ledger claim (scenarios/, ledger.toml)
• New or updated finding (findings/) — none: a capability claim lives in the ledger; a findings/ write-up follows when G-0002 is filed upstream (roadmap §9)
• Cluster / tooling (cluster/, Makefile, scripts/)
• Docs (README.md, docs/)

Checklist

• make check is green (fmt, clippy -D warnings, check, go vet/verify)
• Cluster-backed changes verified with make gate against a real TiKV/PD cluster (exit 0: verdict as expected, both ledger claims XDIVERGE)
• Each new test names the obligation it verifies (scenario doc names G-0002; command round-trip tests cover the new protocol surface)
• The harness carries no workaround for a client-rust bug — the missing capability is answered unsupported, never emulated
• README.md / findings updated (Layout comment; roadmap + rules flipped to landed)

Evidence

═══ G-0002 — RawKV Checksum: client-go computes a server-side crc64 over a range; client-rust has no such request
    scenario: scenarios/raw-checksum.json   expect: diverges   status: OPEN
    XDIVERGE — the gap is still open, and it diverged EXACTLY as declared (2 field(s)).
      checker-checksum · class: oracle='ok' subject='unsupported'
      checker-checksum · unsupported.detail: oracle='<step absent>' subject="client-rust has no raw checksum: …"
LEDGER: every claim holds at the pinned revisions.

Oracle trace evidence: checksum: { crc64_xor: …, total_kvs: 3, total_bytes: 149 } — the ok is inspectable, not bare. Strict mode enforced: the first adjudication attempt was refused ("produced by a DIRTY harness") until the changes were committed — the instrument-pinning gate working as designed.

🤖 Generated with Claude Code