Group page deltas into authenticated macro objects

[FujitsuPolycom]

Resulting behavior

Page-delta publication writes sparkcache-page-delta-manifest/v2 roots over ordered, content-addressed byte extents of at most 64 MiB. A 1,575,821,491-byte delta therefore uses at most 24 physical delta objects instead of the 1,024 objects implied by a 262,144-token logical boundary.

Restore verifies every object digest, copies ordered batches into one authenticated delta buffer, verifies the complete delta digest, applies the page-semantic reconstruction, and verifies the reconstructed snapshot before placement. Reads retain at most four object payloads in addition to the assembled delta; publication retains at most two object payloads per durability batch.

The existing page codec still shares every byte-identical base page and writes only changed or extended page tails. A boundary inside an HMA page still replaces the complete intersecting page.

Technical reason

A recorded 262,144-token restore processed 1,024 delta chunks and took 5,842.236 ms. Storage read and verification consumed 4,437.355 ms, compared with 961.720 ms for host-to-device submission and 313.987 ms for CUDA synchronization. The eight-worker v1 reader still paid one open/read/hash lifecycle per 256-token-derived file and retained all decoded chunks before joining them.

The v2 physical layout removes the dominant per-file scaling without changing logical digest or admission geometry. Increasing the thread count cannot remove that object lifecycle cost.

Compatibility and cache namespace

Cache namespace impact: none. CacheIdentity, digest salts, 256-token admission geometry, chunk geometry for flat snapshots, page codec bytes, and page-tail-cow-v1 remain unchanged.

Schema impact: page-delta roots written by this source use sparkcache-page-delta-manifest/v2. Version 1 page-delta roots remain fully readable and participate in capacity accounting, integrity sweep, invalidation, and reconstruction. Unknown schemas cleanly miss as incompatible. Concurrent v1 and v2 writers for one exact context cannot alias different bytes because manifest publication remains immutable and content-checked.

Direct native placement from separate base and delta extents is unsupported by v2. Restore still materializes one authenticated delta buffer and the verified reconstructed snapshot before Python or native page placement.

Validation

• python -m pytest sparkcache -q — 754 passed, 7 skipped
• python -m pytest deploy -q — 108 passed, 1 skipped
• python -m ruff check . — passed
• JSON profile parsing and git diff --check — passed
• GPU-free regressions cover byte-exact reconstruction, object and descriptor corruption, 24-object live-scale ceiling, bounded read and write batches, base-page sharing, tail-only size reduction, v1 readability, capacity maintenance, and connector integrity sweep
• Deployable source SHA-256: 9b8b2a6863d91f07354dab67d608cc15f551f1a5a7682b89873c7ae6ba468ee5

No image was built or published. No serving process or host configuration was changed.

Composition with the recurrent-boundary contract

A dry integration with SparkCache pull request #31 head 9e779c32b285e00577a7829a75192069d12685dc passes 759 SparkCache tests with 7 skips, 108 deployment tests with 1 skip, and Ruff. The code and regression changes merge without semantic conflict. Git requires three expected textual resolutions: the two deployment source-digest pins and the shared page-delta README paragraph.

The combined deployable SparkCache source SHA-256 is 9fa4ee21963bc8756c43854847a42fe3c2094c3f21b5be47c6b220811f490456. A combined integration commit must write that digest to deploy/deepseek_v4/tp4_profile.json and deploy/glm52_35bpw/profile.json.

Pull request #31's vLLM contract receipt remains valid without regeneration: its contract SHA-256 is 45d7a92b38b836a4f829f02df85e339cfeea860e1080e4663a8340af6c125125, and the combined tree reproduces that hash. A SparkRing image integration must nevertheless regenerate its SparkCache source pin and image/source receipt against the combined commit, Git tree, and deployable source digest, and must use the pull request #31 contract SHA-256.

[FujitsuPolycom]

The resulting behavior and evidence are consolidated in retained draft stack #39 → #42 → #44. Independent heat and SSD research remains in #36. Closing this superseded draft and deleting only its remote head branch.