feat(cloud): implement SessionRepository revision CAS and crash-safe publication

Parent RFC: #1286

Depends on:

- #1336 / #1353 — Session Bundle storage-class and size policy; landed
- #1528 / #1697 / #2013 — Session Bundle artifact, digest, and filesystem-codec contract; landed
- #2369 — quiescent, filtered Session Bundle snapshot production; landed

Unblocks:

- #1415 — fork Cloud Sessions at committed revisions
- future Activation coordinator and fresh-sandbox E2E work from #1286

## Summary

Define and implement the V1 `SessionRepository` control-plane boundary for durable Cloud Session heads and immutable `SessionCheckpointManifest` revisions.

A revision is not a direct pointer to one Bundle. Its head CAS-points to an immutable checkpoint Manifest; V1 uses a single `compatibilityBundle` component produced by #2369. This retains a small, reviewable contract now while allowing later Manifest versions to describe additional durable Session components without redefining a Session or introducing a universal Storage API.

## V1 model

```text
Session head (control plane; CAS)
-> immutable SessionCheckpointManifest v1
-> compatibilityBundle: immutable, verified #2369 Bundle
```

The Bundle remains the safe, filtered, quiescent `state/ + workspace/` snapshot created by #2369. #2370 consumes that opaque immutable output; it does not parse or reinterpret its snapshot policy.

Future Manifest versions may reference event-log heads, Workspace snapshots, Artifact references, authorized Memory read/revision references, and parent lineage. Their precise schemas, ownership, and consistency rules are deliberately out of V1 scope.

## Problem

The Session Bundle codec produces a local immutable `tar.zst` artifact with an archive digest. It does not provide durable Cloud Session identity, exact committed-revision lookup, conditional head publication, stale-writer protection, crash-consistent target creation, or durable Fork idempotency.

Treating that Bundle itself as the permanent Session revision would also make the V1 compatibility representation the only possible Session shape. We need a small, strongly consistent Session head that identifies one immutable checkpoint Manifest, while the large state bodies remain independently publishable immutable objects.

## Responsibility boundary

The `SessionRepository` is authoritative for:

- Cloud `sessionId` and `agentId` bindings;
- current Session head and opaque Repository revision;
- create-if-absent Session creation and conditional head publication;
- exact checkout of the Manifest named by `{ sessionId, revision }`;
- commit provenance such as `lastCommittedActivationId`, when carried as control-plane metadata;
- Fork lineage in target Session metadata; and
- durable Fork operation and idempotency records required by #1415.

It does not own:

- quiescent `state/ + workspace/` snapshot production, Bundle encoding, or Bundle hydration (#2369 and #1528);
- the schema or implementation of future Event, Workspace, Artifact, or Memory components;
- global or workspace-scoped Memory contents, Secrets, credentials, or Secret injection;
- leases, Activation scheduling/deduplication/outcomes, reply delivery, Sandbox lifecycle, or Runtime scheduling; or
- arbitrary historical retention, copy-on-write optimization, reachability analysis, or object garbage collection.

Session heads, revisions, Fork records, and operation identities remain control-plane metadata; they are not #2369 Bundle payload.

## Logical ports and V1 contract

The design has two distinct ports. They may share physical infrastructure, but they must not share away their different semantics:

```ts
type ImmutableObjectRef = {
objectRef: string;
digest: Sha256Digest;
bytes: number;
mediaType: string;
};

type SessionCheckpointManifestV1 = {
schemaVersion: 1;
compatibilityBundle: ImmutableObjectRef;
};

type StoredSessionCheckpoint = {
manifest: ImmutableObjectRef;
value: SessionCheckpointManifestV1;
};

interface ImmutableObjectStore {
publish(input: ImmutableObjectInput): Promise;
assertReadable(ref: ImmutableObjectRef): Promise;
}

interface SessionRepository {
checkoutExact(ref: SessionRevisionRef): Promise;
createSession(input: CreateSessionInput): Promise;
commit(input: CommitSessionRevisionInput): Promise;
claimFork(input: ClaimForkInput): Promise;
completeFork(input: CompleteForkInput): Promise;
}
```

Exact names remain subject to contract review. `CommittedSessionRevision` returns the exact stored checkpoint Manifest, not a direct Bundle field. The V1 `compatibilityBundle` must have suitable media type, byte count, immutable reference, and the #2369 archive digest needed by #1528 inspection/hydration.

A local backend and a future remote backend must satisfy these same logical contracts. A last-write-wins remote object store is not by itself a Session control plane: it cannot replace the head-CAS and idempotency semantics.

## Publication, checkout, and retention

Publication order is fixed:

1. #2369 prepares and packs the V1 Bundle, returning its archive digest.
2. Publish and verify the immutable Bundle object.
3. Create, publish, and verify the immutable `SessionCheckpointManifest` that names that Bundle.
4. Allocate the new Repository revision and CAS-publish the Session head last, or create the Session with an absent-key condition.

A visible head must never name an unreadable Manifest or a Manifest whose required Bundle is unreadable or digest-mismatched. A failed head CAS may leave unreachable immutable objects; that is safe and later garbage-collectable. The Repository revision is opaque and is never reused as an object digest.

`checkoutExact({ sessionId, revision })` reads the authoritative head, compares the requested revision with the retained revision, and resolves the immutable Manifest and its V1 Bundle under integrity checks. It fails closed and never substitutes a newer head, Manifest, or Bundle.

V1 retains only the currently addressable revision per Session. After a head move, a former revision returns `revision_not_available` or `source_revision_not_available`; arbitrary historical retention is out of scope.

## CAS, Fork idempotency, and crash recovery

- `commit` succeeds only when the current head equals `expectedRevision`; stale writers receive a stable conflict.
- Revision allocation and head replacement have one linearization point. Retrying an admitted commit identity returns or reconciles the original result rather than allocating another revision.
- Source and Fork target heads have independent CAS sequences.
- A durable `forkId -> targetSessionId` pending record is conditionally claimed before target checkpoint publication. A retry with identical parameters resumes or returns the same operation; incompatible reuse fails `idempotency_conflict`.
- The target sequence is: claim Fork record; publish/verify target immutable components and Manifest; create target Session with `createdByForkId`; complete the Fork record with the target revision.
- A crash before target creation resumes from pending. A crash after target creation verifies `createdByForkId`, reconciles the target checkpoint, and completes the existing record. A target from another Fork is never adopted.
- Completed Fork identities have explicit durable V1 retention.

#1415 owns fork hydration, state-semantic identity re-keying, repacking, forkability checks, and orchestration; this Issue supplies only the durable control-plane primitives it consumes.

## Stable error model

The public error set remains bounded. Candidate codes include:

```ts
type SessionRepositoryErrorCode =
| "session_not_found"
| "revision_not_available"
| "revision_conflict"
| "session_already_exists"
| "idempotency_conflict"
| "object_not_found"
| "integrity_mismatch"
| "quota_exceeded"
| "io_failure";
```

Exact names remain subject to contract review.

## Acceptance criteria

### Revision and checkout

- [ ] Session heads and Repository revisions are external to the #2369 Bundle.
- [ ] A head resolves to a readable, integrity-checked `SessionCheckpointManifest` V1 whose required `compatibilityBundle` is also readable and integrity-checked.
- [ ] V1 exact checkout returns only the explicitly requested retained Manifest revision; a moved head never falls forward to latest.
- [ ] A source-head race returns either the requested committed Manifest/Bundle or a stable not-available error, never an unintended revision.
- [ ] Source and Fork target use independent revision/CAS sequences.

### Publication and integrity

- [ ] Immutable Bundle publication and verification finish before immutable Manifest publication; Manifest publication and verification finish before head CAS or Session creation.
- [ ] No visible head can name an incompletely published Manifest or required V1 Bundle.
- [ ] The trusted #2369 archive digest is retained in the V1 Bundle component and supplied to full #1528 validation before hydration is accepted.
- [ ] Missing, replaced, truncated, or digest-mismatched Manifest or Bundle bytes fail closed.
- [ ] A crash before head CAS leaves only unreachable immutable objects; a crash after successful CAS leaves a completely readable checkpoint.

### CAS, creation, and portability

- [ ] Stale commits cannot overwrite a newer head; Session create-if-absent has one linearization point.
- [ ] A fake/in-memory implementation enables deterministic coordinator/Fork tests.
- [ ] The same conformance semantics can be exercised by a local backend and a future remote backend without making backend paths Session identity.
- [ ] The chosen durable backend later covers concurrent commit/create and crash recovery with multi-process/storage integration tests.

### Fork idempotency

- [ ] `forkId` is durably claimed before target Session checkpoint publication.
- [ ] Same `forkId` plus identical parameters returns or resumes the same target; incompatible reuse fails deterministically.
- [ ] Crashes before and after target creation recover without duplicate targets.
- [ ] `createdByForkId` prevents adoption of a target produced by another operation.

## Implementation split

This is one dependency-graph work item and lands independently from #2369. A reviewable implementation may use two PRs:

1. public contract, V1 Manifest model, in-memory conformance implementation, CAS/idempotency state machine, and race tests;
2. durable backend, digest-verified object and Manifest publication, crash recovery, and multi-process integration tests.

AI assistance disclosure: OpenAI Codex helped structure and draft this Issue update; reviewed and posted by me.

---

## Follow-up plan: local Runtime integration (proposed, 2026-09-09)

This section records the consumer-integration plan motivated by [Discussion #4666](https://github.com/apache/maka/discussions/4666). It does **not** redefine the V1 Repository responsibilities or replace the original acceptance criteria above. Runtime orchestration remains outside `SessionRepository`. The work below is proposed, not completed or an adopted project-wide migration decision.

The two stages are: (1) complete the local persistence boundary without changing existing transaction/recovery semantics; (2) wire checkpoint publication and supported restoration. For reviewability, stage 2 is split into two PRs. **PR 1/2/3 below refer to new follow-up work, not the earlier #4662/#4674 implementation split.**

Planning baseline: key production paths at `a41d3ac4a76d8c5ac5154032acb9dbb123e847a6` (2026-09-09). Implementation should start from the then-current main.

### Invariants and scope

- Existing SQLite/file stores remain authoritative for live local commits and ordinary in-place restart recovery. A Repository Head identifies a published checkpoint, which may lag live state. An older checkpoint must never automatically overwrite newer local state.
- Do not introduce synchronous dual writes of every live commit into the checkpoint Repository. Keep metadata revisions, event ordinals, and checkpoint revisions distinct.
- The Repository is the only checkpoint Head authority. Host operation receipts and read caches are not another writable Head.
- Preserve root leases, authenticated storage capabilities, admission, atomic domain operations, and failure semantics. The Repository's file writer lock is not a Runtime execution/Activation lease.
- WorkHub is a compatibility consumer, not a product redesign. Its coordination record and the target's pending message admission must still commit atomically, including target creation when applicable.
- Checkpointing starts as an explicit, disableable Host management capability, not a model tool or automatic packaging on every message/turn. It must be composed into the real Host, not only a standalone demo.
- Out of scope: WorkHub UI/routing changes, Memory retrieval redesign, remote backends, cross-Host coordination/fencing, whole-instance roaming/restoration, a new Agent product entity, wholesale conversion of SQLite into disposable projections, and #1415's identity-rekeying Fork workflow.

### Follow-up PR 1 — persistence contracts and local crash recovery

Suggested title: `refactor(runtime): isolate local persistence contracts without changing commit semantics`.

Local persistence interfaces already exist in `packages/storage/src/execution-stores.ts` and `storage-writer-composition.ts`; the Host and SessionManager already consume injected stores. Reuse these boundaries rather than inventing a parallel universal Storage API.

Implementation:

- Inventory the required capabilities and their transaction boundaries: Session catalog/metadata, canonical event/transcript reads, message and Root Turn admission, Tool T1/T2, continuation, and atomic WorkHub assignment.
- Narrow overbroad consumer dependencies and extract backend-independent contracts only where concrete implementation types leak. Keep local adapter construction, lifetime, and close ownership at composition. Leave already-suitable ports unchanged.
- Preserve whole domain operations such as `assignWorkHubMessage`; do not replace them with unrelated per-Session CAS calls or arbitrary caller-assembled transactions.
- Preserve existing Goal, Memory, and Artifact domain stores. Do not bypass capability/lease validation to make test injection easier.

Acceptance:

- [ ] Production consumers use the intended contracts, existing data formats and transaction guarantees remain compatible, and dependency/type checks prevent new concrete SQLite construction from escaping composition.
- [ ] A real Host subprocess is terminated **after the WorkHub assignment transaction commits but before the target consumes its pending admission**. After reopening all owners/stores and running production recovery, the same delegation is visible and the same target message proceeds without duplicate target/delegation/first dispatch in this crash window.
- [ ] Cover `create_new`, `delegate_existing`, identical/conflicting action retries, transaction rollback, and delegated attachment readability; regress existing stop/replacement/continuation behavior. This does not claim exactly-once arbitrary external side effects.

Use the current WorkHub Runtime Turn/action path and current transcript projections, not an outdated coordinator mock or merely checking old SQLite rows.

### Follow-up PR 2 — Host checkpoint publication

Suggested title: `feat(runtime-host): publish verified local session checkpoints`.

Implementation:

- Compose a Host checkpoint coordinator with the existing Runtime quiescent snapshot service, file Repository, and immutable-object store. Add the package exports actually required by these consumers. Do not move Runtime scheduling, quiescence, or Memory interpretation into the Repository.
- Establish a trusted, durable `makaSessionId -> repositorySessionId + agentId` binding outside Bundle payload. Prefer an appropriate existing durable identity; otherwise provision and persist a dedicated local-authority identifier once. Never use a per-start `hostEpoch` or filesystem path as durable Agent identity. This is a binding, not a new Agent product entity.
- Persist the minimum per-request recovery facts: stable request/commit identity, binding, expected revision, frozen Bundle/Manifest references, and outcome. Reuse suitable control metadata facilities; this record is not another Head.

Publication sequence:

1. Validate authority/binding, register the request, and read the expected Head or absence.
2. Acquire a stable write boundary and copy the filtered state and Workspace into private staging.
3. Release the live-state fence once the private copy is complete; pack from that copy.
4. Use `publishSessionCheckpointV1` to publish and verify the Bundle and Manifest.
5. Persist the exact commit inputs, then call `createSession` or revision-CAS `commit`.
6. Return or reconcile the committed result using the same operation identity.

A retry must not take a different snapshot under the same commit identity. A CAS conflict must not silently rebase an older snapshot onto a newer Head. If creation succeeded but its response was lost, reconcile only the exact binding and checkpoint, never adopt an unrelated existing Session.

Quiescence must cover the entire state/Workspace-copy interval. Coordinate Host admission, Runtime mutation lanes, Workspace writers, Artifact/context-offload locks, and maintenance/GC under an audited lock order. Reject active execution, pending admissions, unresolved operations/approvals, live background writers, conflicting shared Workspaces, or otherwise unprotected mutation. A one-time idle check or per-file change detection is not proof of a consistent snapshot of an arbitrarily externally writable directory. Unsupported sources must fail explicitly or require an offline/snapshot-capable path.

Preserve filtering, Secret exclusions/confirmation, cancellation, deadlines, quotas, and ownership-bounded staging cleanup.

Acceptance:

- [ ] A real Bundle passes through verified object and Manifest publication before Head creation/CAS; incomplete or corrupt components never become a visible checkpoint.
- [ ] Independent processes racing create/commit produce the correct winner/conflict; crashes before/after CAS and lost responses recover without duplicate revisions or changed retry inputs.
- [ ] Controlled races with admission, Workspace writers, and maintenance enforce the snapshot boundary. Busy, unsupported, conflict, and publication failures are observable; optional checkpoint failure does not undo a successful live message commit.

### Follow-up PR 3 — exact loading and supported Runtime restoration

Suggested title: `feat(runtime-host): restore supported sessions from exact checkpoints`.

Implementation:

- Use `checkoutExact` for a requested retained revision. Use `checkoutCurrent` only when current was explicitly requested, and freeze its result; never fall forward after an exact-checkout failure.
- Pass `materializeSessionCheckpointV1`'s trusted `expectedArchiveDigest` into the existing codec's inspection/hydration. Verify envelope/state identity, binding, and format compatibility.
- Restore only into a fresh Host-managed isolated destination. Hydration completion is not execution admission: validate dependencies, configure the target Workspace/permissions, and run actual Host recovery before allowing execution.
- Initially admit only quiescent ordinary Sessions with complete supported dependencies and no unresolved external operations. The source execution must be reliably stopped/fenced. Different directory leases do not prevent two copies of one Session from running; if safe takeover cannot be established, reject activation or restrict the result to inspection. Cross-device fencing is not supplied by this work.
- Preserve validated identity for restoration. A concurrently executable new identity belongs to #1415's re-key/repack Fork workflow.
- Check coordination/target reference closure before activating WorkHub-related Sessions. Two independently produced Session checkpoints do not establish a consistent WorkHub restore point. Eligibility must use authoritative source relationships, not assume a relationship never existed because export filtering removed it.
- Validate actual current-schema coverage for RuntimeEvent transcripts, Tool journals, Artifact/context-offload data, and Session-scoped Goal/Plan state. Do not silently restart schedulers merely because rows were restored. Global/workspace Memory, credentials, machine capabilities, and external resources are not implicitly transferred; required target configuration comes from its trusted Host.

Acceptance:

- [ ] A real Session is published, retrieved, hydrated, and recovered by a new test Host; its user-visible history, tool results, and files are correct, and a subsequent controlled turn executes.
- [ ] Existing targets/live data are never overwritten. Stale revisions, missing/corrupt objects, identity mismatch, unsupported dependencies, and unsafe takeover fail closed.
- [ ] A crash after hydration but before activation safely retries; ordinary in-place restart continues from newer live state rather than rolling back to the last checkpoint. WorkHub in-place recovery from PR 1 remains distinct from whole-WorkHub checkpoint restoration.

### Delivery and verification

- Sequence: PR 1 -> PR 2 -> PR 3. Each should remain independently reviewable; the complete local-integration milestone includes supported restoration.
- Start new branches from current main; do not continue the historical #4662 branch. No new follow-up issue or PR is created by this plan update.
- Capture baseline message-admission, WorkHub-assignment, transcript-read, and restart costs; measure snapshot fence duration, per-stage publication/restoration time, peak memory, and disk usage. Establish budgets with repeatable measurements rather than promise zero overhead.
- Version new control metadata/checkpoint artifacts separately. Disabling the feature preserves the existing live path; no destructive migration or automatic rollback over user data.
- Validate contracts/types, real SQLite transactions, Host subprocess crashes, snapshot/Repository/codec integration, existing Storage/Runtime/Host suites, and platform-specific locking/publication behavior including Windows.
- Independent-process Repository CAS and real Bundle materialize-to-hydrate tests also supply evidence relevant to the original #2370 acceptance criteria. Planned tests are not passed tests; original V1 closeout and follow-up delivery remain separately identifiable.

中文：本地 Runtime 接入计划

这部分将 #4666 的架构方向落到本地使用路径，作为后续实施计划记录在本 Issue 中，**不改写上面的 V1 Repository 职责和原验收标准**。Runtime 编排仍由 Runtime/Host 负责。以下是待实施、待社区评审的计划，不表示已完成，也不代表已经接受的全项目迁移决定。

仍是两个阶段：先补齐本地持久化边界、保持现有事务和恢复语义，再接通 checkpoint。为了便于检视，第二阶段拆成“发布”和“恢复”两个 PR。下文的 PR 1/2/3 是新的后续工作，不是之前的 #4662/#4674。

**共同约束**

- SQLite 和现有文件继续承载本地日常提交及原地重启恢复的权威状态；Repository Head 表示已发布 checkpoint，可以落后于本地状态，不能拿旧 checkpoint 自动覆盖更新的数据。
- 不引入每次日常提交都同步写 checkpoint 的双写事务。元数据 revision、事件 ordinal、Repository revision 各有含义；Repository 是 checkpoint Head 的唯一权威。
- 保留现有 root lease、权限、准入、完整领域事务和故障处理；Repository 文件写锁不是 Runtime Activation lease。
- WorkHub 是兼容性使用方，不重做产品。“协调 Session 记录委派”和“目标收到待执行消息”继续原子提交，必要时同事务创建目标。
- 首版是显式、可关闭的 Host 管理能力，不是模型工具，不默认每条消息或每轮对话打包。
- 不包括 WorkHub 界面/路由、Memory 检索、远端后端、跨 Host 协调、完整实例漫游/恢复、独立 Agent 产品实体、全量 SQLite 投影化，以及 #1415 的身份重写 Fork。

**PR 1：补齐持久化契约，验证本地崩溃恢复**

复用现有 `execution-stores.ts`、`storage-writer-composition.ts` 和已注入的 Store；核对 Session 元数据、事件/对话查询、消息/Root Turn 准入、Tool T1/T2、续跑和 WorkHub 委派的能力及事务边界。只收紧真实存在的实现耦合与过宽依赖，后端构造和生命周期仍在组装入口，不另造通用 CRUD API，也不绕过 lease/身份校验。

重点验收：通过最新 WorkHub Runtime Turn/action 入口提交委派，在**事务提交后、目标消费 pending admission 前**强制结束真实 Host 子进程；重启全部 owners/stores，走正式恢复和查询路径，确认同一委派可见、同一消息继续，不重复创建目标或本场景的首次派发。

覆盖 create_new、delegate_existing、幂等/冲突重试、事务回滚和附件可读性；回归停止、替换、续跑。这个场景不代表任意外部副作用都能 exactly once。

**PR 2：接通 Host checkpoint 发布**

Host 协调现有快照、Repository 和对象存储，必要时补齐跨包导出。建立可信、稳定的 `makaSessionId -> repositorySessionId + agentId` 绑定，放在 Bundle 之外；优先复用适用的持久身份，否则首次启用生成并持久保存专用标识，不用每次启动变化的 hostEpoch 或机器路径充当身份。

流程：验证权限和绑定 -> 登记请求、读取预期 revision -> 在安全写入边界中复制私有快照 -> 释放运行状态排他 -> 打包并验证发布 Bundle/Manifest -> 固定提交输入 -> create/CAS -> 返回或协调提交结果。

保存最小操作恢复记录；同一提交身份不能在重试时换成另一份快照。CAS 冲突直接报告，不能将旧快照自动覆盖新 Head。创建响应丢失时，严格核对原绑定和确切 checkpoint。

安全边界覆盖整个状态/Workspace 复制区间，并协调准入、Runtime mutation lane、Workspace 写入、Artifact/context-offload 锁及维护/GC，审计锁顺序并测试竞争。正在执行、待准入消息、未解决操作/审批、活跃后台写入、共享 Workspace 冲突或无法证明安全的外部可写目录，应明确拒绝或要求离线/具备快照语义的路径，不能只检查“空闲”。保留 Secret 过滤/确认、配额、取消、超时和按所有权清理。

验收真实 Bundle -> Manifest -> Head、独立进程并发 create/commit、CAS 前后崩溃与丢失回执、各类写入竞争及明确可观察的失败；checkpoint 失败不撤销已经成功的日常消息提交。

**PR 3：精确加载与受限恢复**

通过 checkoutExact 读取指定 retained revision；仅在明确请求 current 时读取并固定当前版本。materialize 后携带可信摘要进入 codec 校验和 hydrate，验证 Session 身份、绑定和格式。

只恢复到全新隔离目标；解压完成不等于可以执行。补齐目标配置、权限、依赖并进入真实 Host 恢复后，才授予执行资格。首批支持静止、普通、无未解决外部操作、依赖完整的 Session；源执行必须已可靠停止/隔离，不同目录的锁不能防止同一身份的两份副本并发运行。无法保证接管安全则拒绝激活或限制为检查。恢复保留身份，需要并行新身份的副本属于 #1415。

单 Session 包不等于完整 WorkHub 一致恢复点；从导出时的权威关系检查跨 Session 依赖，不能因为过滤后看不到关联就判定无依赖。核对当前 RuntimeEvent transcript、Tool journal、Artifact/context-offload、Session-scoped Goal/Plan 的实际覆盖与恢复能力；不自动搬迁全局 Memory、凭据、机器能力或重启未知调度。

验收真实发布/取回/hydrate/新 Host 恢复及下一轮执行，验证历史、工具结果和文件；缺对象、损坏、旧 revision、身份不符、依赖不完整和不安全接管均明确失败。恢复不能覆盖现有目标或更新的本地数据；覆盖 hydrate 后、激活前崩溃重试。WorkHub 的原地重启兼容性与整个 WorkHub 的 checkpoint 恢复分别验收。

**交付与性能**

按 PR 1 -> PR 2 -> PR 3 推进，从届时最新 main 开新分支。记录日常准入/委派/读取/重启基线，测量快照持锁时间、各阶段耗时及内存/磁盘，不预先承诺没有性能影响。新增控制元数据单独版本化，关闭功能保留原 live 路径，不进行破坏性迁移。

检查类型/契约、真实事务、Host 子进程崩溃、snapshot/Repository/codec 集成、既有 Storage/Runtime/Host 测试与 Windows 等平台文件锁/发布行为。独立进程 CAS 和真实 Bundle materialize -> hydrate 测试也可补充原 #2370 的验收证据，但本计划不将未运行的测试标记为通过。

AI assistance disclosure: OpenAI Codex assisted with structuring and drafting this follow-up plan and its Chinese translation.