Sekiban DCB 10.7.0 — serialized-commit wire contract: normative spec, golden vectors, versioned envelope

This release hardens the serialized-commit wire contract — the JSON surface used by WASM/remote clients to submit commits. It was motivated by #1087/#1088, where a differently-shaped downstream contract was mistaken for the framework contract and produced a confusing mixed-version 500. Investigation proved the framework contract itself has never changed (byte-identical DTOs across 10.2.2 → 10.6.0); what was missing was any machine-verifiable definition of it. This release closes that gap. Everything is additive: no data migration, no behavior change for existing paths, and programs built on the 10.1.x line keep working unchanged (proven in CI with fixtures taken from the actual dcb-v10.1.17 bytes).

Normative wire spec + frozen golden vectors (fixes the #1088 confusion class)

• The serialized-commit contract is now documented normatively (EN/JA): every field, its type and encoding (base64 payload, eventPayloadName, per-event tags as the authoritative model, consistencyTags with lastSortableUniqueId), plus the exact serializer settings (naming policy, property order, encoder/escaping, null handling, UTF-8).
• Golden wire vectors — canonical JSON fixtures frozen from the actual dcb-v10.1.17 types and bytes, with provenance — are now CI-enforced in both directions (byte-exact serialization, exact deserialization), including multi-event commits with heterogeneous per-event tags and non-ASCII names. Any accidental wire drift (serializer settings, renames, framework upgrades) fails CI immediately.
• Contract ownership is documented: the canonical types live in Sekiban.Dcb.Core (SerializedCommitRequest / SerializableEventCandidate / ConsistencyTagEntry / ISerializedSekibanDcbExecutor). Endpoints claiming compatibility must conform to the spec and golden vectors; adapters collapsing per-event tags into a shared set may only do so when all tag sets are identical and must reject the rest explicitly.
• Wire-name pinning lives in an additive contract-owned serializer surface — existing DTOs gained no attributes, and legacy ambient serialization (including PascalCase output under fresh JsonSerializerOptions) is proven byte-for-byte unchanged.

Versioned envelope + two-phase acceptance (fixes the mixed-version 500 class)

• A new versioned commit envelope carries an explicit contract version discriminator. Acceptance is two-phase: the version is read before any typed payload binding.
  • Known version → processed with semantics identical to the legacy path (routed to ISerializedSekibanDcbExecutor).
  • Unknown version → a typed UnsupportedVersion error before payload deserialization, reservation, EventId allocation, or any store call — never a null-reference 500.
  • Malformed shapes (wrong-typed/duplicated version, malformed known-V1 payload) → a typed ShapeError, with no secret-bearing serializer internals leaked in the error graph.
• Version-less input remains first-class: it is recognized as the legacy official shape and accepted losslessly (safe because the contract provably never changed). Existing 10.1.x/10.2.x clients need no changes.

Notes

• No data migration; zero default-behavior change. Stored events, schemas, and all existing write/read paths are diff-guarded unchanged.
• New public API (minor bump): versioned envelope DTOs, the acceptance surface, and the typed contract errors. No existing interface gained members.
• Docs: serialized contract & WASM boundary docs updated (EN/JA), including guidance for downstream endpoints claiming compatibility.

Related: #1087, #1088, J-Tech-Japan/SekibanWasmRuntime#248.