MST/2 T04: persistent projection (locators/segments) and composite namespaces (import/binding/aggregate/release)

[Ivanbeethoven]

Context

MST/2 serves every scope as a native view today. The pages are built on the
fly from the fixed Git tree, deterministically (page_id is stable across
requests because the build is canonical), and chunk maps are built on demand
from a verified blob with a bounded in-process cache
(src/ceres/snapshot/chunks.rs).

That is functionally correct but it is not the T04 shape, and it is the gate for
everything composite:

• there is no persistent projection, so every request re-derives metadata from
  Git;
• capabilities.features.bindings and immutable_release are false, because
  there is no import / binding / aggregate / release namespace;
• the spec 11 §10 client-side incremental story currently has to lean on page
  ids alone, because there is no server-side notion of a reused subtree.

Scope

1. Persistent projection (spec 08, spec 10 §2/§4):
   • a locator abstraction (Locator {storage_domain, kind, backend_id, key, offset?, length, generation, state}) with at least RAW_OBJECT plus
     reliable range reads in this version;
   • publish a range-readable representation before advertising range/chunk
     capability — spec 07 §8 forbids rebuilding the whole file per chunk;
   • persistent metadata pages that are byte-identical to what the on-the-fly
     builder produces today. This is the compatibility bar: if a persisted page
     differs, the wire format silently changed.
2. Source projection + graft + CoW (spec 08): a fixed source subtree
   projected into a scope, with copy-on-write for the parts that change and
   correct handling of a shared commit tree.
3. Composite namespaces: import bindings (longest-prefix, historical
   source retention), aggregate, release, and the source_subpath rule —
   a binding whose source is a subdirectory of another repo, not the root.
4. Conflicts: file/dir conflict resolution across sources, synthetic
   ancestors, and scope attestation (a candidate view must not advance the
   default namespace).

Acceptance

• NS-01..10 and ING-01..10 from spec 16 §2/§3, each run through the real
  endpoints.
• Byte-identity gate: for a fixed commit, the persisted page set and the
  on-the-fly build produce identical page_ids and identical pagination
  results. A test that fails loudly if any page differs.
• An imported source that is later updated produces a new view whose unchanged
  subtrees reuse the previous pages (the server-side counterpart of the client
  reuse work), with the reuse measured rather than assumed.
• capabilities only flips bindings/immutable_release after the
  corresponding acceptance passes.

References

• Spec 08 (ingest and incremental projection), spec 10 §2/§4, spec 02
  (namespace/binding model), spec 07 §8
• src/ceres/snapshot/{pages,chunks,resolver,descriptor}.rs,
  src/ceres/pack/import_repo.rs

[Ivanbeethoven]

Scope note (recorded when this was filed): the contract side of composite namespaces is tracked in gitmono-dev/scorpiofs#55 (research epic #39) — what a namespace crossing native scopes, import repositories and intermediate directories must mean, and how path ownership and import revisions are frozen. This issue is the implementation in mega2 and should not start before that contract is settled.

What can proceed in parallel here: the persistent projection itself (locators/segments, the byte-identity gate against the on-the-fly builder) does not depend on the composite contract, because it only has to reproduce today's native-scope pages exactly. The namespace-binding parts (import/binding/aggregate/release, source_subpath, file/dir conflicts across sources) do.