docs(CH-012): define durable Rumble client contracts

[flemming-n-larsen]

Acceptance brief

• Plan item: P-003/M-008 remains wanted.
• RCL-001: draft; contract clarified so practice configuration needs no registered identity, while full integration evidence remains pending.
• RCL-002–RCL-005: draft; synchronization, selection, mode isolation, and replay-bound result evidence remain pending in rumble-client.
• RCL-006: draft; durable post-publication acknowledgement is defined here and receiving-side evidence is proposed by Fix durable result receipts rumble-data#5.
• RCL-007: draft; batches split into 1–60-result issues and use post-publication receipts; client evidence remains pending.
• RCL-008–RCL-009: draft; multi-runtime execution and the end-to-end ranked path remain pending.
• Merge binds ADR-0044’s publication-before-receipt and idempotent-retry contract; it supersedes no accepted artifact.

Summary

• define CAP-016 ownership, RCL-001 through RCL-009, and the Rumble client trust boundary
• publish successful ingestion receipts only after accepted facts reach the canonical repository
• make identical retained-result retries successful without admitting conflicting duplicates
• keep fork-PR submission deferred until rumble-data implements that transport
• align batching, practice identity, journal quarantine, evidence, and roadmap wording across all live carriers

Root cause

The original issue-ops design allowed a receipt to be published before the accepted fact commit was pushed. A later aggregation or push failure could therefore cause the client to delete its only queued copy. Several older design carriers also still described fork-PR as a V1 transport and one journal as one issue.

Status

This is a draft CH-012 continuation PR. External receiving-side implementation is in robocode-dev/rumble-data#5; the remaining client implementation and evidence tasks stay open.

Validation

• clue validate — OK, 131 artifacts
• git diff --check