Commit the Rust-written content vectors and document the Rust content path

content-vectors.rs-written.json is written by cultnet-rs and is identical
to the reference's file. transport-planes.md and content-sessions.md name the
Rust runtime's content path as the explicit compatibility path on the session
the client already holds, lasting until an authenticated content connector
exists behind the same fetch_content owner; runtime-parity-scope.md gets the
evidence row.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/runtime-parity-scope.md

@@ -73,6 +73,16 @@ to speak CultNet or participate in CultMesh.
   `tests/GameCult.Networking.Tests/SelectionParityVectorTests.cs` carry the
   semantic ones. A single rows-to-bytes path driving both halves in one call
   remains its own cut (R-AR) and is not part of this claim.
+- CultMesh content plane (`cultmesh.content_chunk_request.v1` and `.response.v1`
+  plus the CDN manifest, C#/Rust only): byte parity in both directions, and the
+  reference's answer to a chunk request, including its failure spellings.
+  `packages/cultnet-rs/tests/content.rs` and
+  `tests/GameCult.Mesh.Tests/CultMeshContentVectorTests.cs` judge
+  `contracts/cultmesh/content-vectors.cs-written.json` and
+  `content-vectors.rs-written.json`. Rust carries these chunks only on the
+  session the client already holds (see `src/GameCult.Mesh/docs/transport-planes.md`);
+  it has no authenticated content connector, so it claims no TCP+TLS or QUIC
+  content path.
 
 ## Expansion Work Outside The Current Parity Claim
 

src/GameCult.Mesh/docs/content-sessions.md

@@ -47,6 +47,14 @@ The content protocol uses one bounded response per manifest chunk. A snapshot
 response containing `gamecult.mesh.cdn_artifact_chunk.v1` payload records is a
 legacy transport path and must not be used for bulk delivery.
 
+The Rust runtime speaks the same chunk messages through `cultnet-rs`
+`fetch_content`, which verifies every chunk and then the whole body, and
+`answer_content_chunk_request`, which mirrors the legacy server's validation
+order and error spelling. Its transport is an explicit closure over the session
+the caller already holds, carrying the chunks as ordinary schema frames until
+Rust has an authenticated content connector; the chunk bytes, manifest shape
+and verification do not change when that connector arrives.
+
 The transfer owner may keep a bounded window of requests in flight per content
 hash (four by default, never more than 32). Candidate chunks can arrive out of
 order, but only the transfer owner writes them, and it flushes and checkpoints

src/GameCult.Mesh/docs/transport-planes.md

@@ -102,6 +102,14 @@ lower priority than TCP. Existing hot-state publishers that still package
 payloads as schema messages must move to the realtime connector contract; the
 new seam does not pretend that migration has already occurred.
 
+The Rust runtime's content path is this compatibility path, chosen explicitly:
+`cultnet-rs` sends chunk requests and reads chunk responses on the session the
+client already holds, byte-identical on the wire to
+`CultMeshLegacyRudpContentServer` (`fetch_content` and
+`answer_content_chunk_request`). It is never an implicit default, and it lasts
+until Rust has an authenticated content connector (TCP+TLS or QUIC), which will
+sit behind the same `fetch_content` owner rather than beside it.
+
 ## Security and release gate
 
 The current TCP control and content connectors are plaintext and therefore