cultmesh-ts/content: README section and CI step naming

Builds. Docs and a workflow name/comment only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.github/workflows/cultmesh-portability.yml

@@ -119,13 +119,14 @@ jobs:
       - name: Verify the browser client against the shared TypeScript verifier
         run: npm run test --workspace packages/cultmesh-browser
 
-      # The realtime frame codec. Its byte parity rests on two vector files,
+      # The realtime frame codec and the HTTP content chunk provider (content.test.ts,
+      # its answers over node:http). The codec's byte parity rests on two vector files,
       # contracts/cultmesh/realtime-frame-vectors.json written by the C#
       # reference and decoded by this step, and realtime-frame-vectors.ts-written.json
       # written by this codec and decoded by the C# step below. Neither half ran
       # in CI on any OS until these two steps existed, so a codec that agreed
       # only with itself would have gone green.
-      - name: Verify the realtime frame codec with the TypeScript codec
+      - name: Verify the realtime frame codec and the content provider with the TypeScript runtime
         run: npm run test --workspace packages/cultmesh-ts
 
       # Both directions of the CultMesh authority vectors: the C#-written

packages/cultmesh-ts/README.md

@@ -516,3 +516,30 @@ negotiation, watch callbacks, and latest-frame cursor contracts for non-C#
 clients. The native C# path owns shared-memory rings and GPU-handle integration
 points. CultCache page append/readback remains the durable recording or
 nonlocal fallback.
+
+## Content Chunks over HTTP(S)
+
+`cultmesh-ts/content` answers the C# HTTPS connector's request, `GET` or `HEAD`
+`<mount>?chunkHash=<hex>&recordKey=<key>`. The mount path is the host's; the
+handler reads only the query. Every chunk is hashed against its name before a
+byte is sent, so a corrupt or swapped file answers 500 and never leaves the
+process, and chunks are never served by path.
+
+The directory store reads a flat `<root>/<hex>` layout. The publisher writes it
+from `packContent`'s chunks (an artifact of one chunk is the file named by its
+content hash). The store never writes, lists or caches. TLS and concurrency
+bounds belong to the host: memory is at most `maxChunkBytes` per in-flight
+request. `onServerFault` reports every 500 (`hash-mismatch`, `too-large`,
+`store-error`) for health.
+
+```ts
+import { readFileSync } from "node:fs";
+import { createServer } from "node:https";
+import { createContentChunkHandler, createDirectoryChunkStore, toNodeListener } from "cultmesh-ts/content";
+
+const handler = createContentChunkHandler(createDirectoryChunkStore("/srv/content"), {
+  onServerFault: fault => console.error("chunk fault", fault.kind, fault.chunkHash),
+});
+createServer({ key: readFileSync("key.pem"), cert: readFileSync("cert.pem") }, toNodeListener(handler))
+  .listen(8443, "127.0.0.1");
+```