feat(storage): publish immutable research Versions and scoped restoration #1535

Native implementation child and blocker of #1350 in M11. This issue covers only the corresponding existing acceptance criteria; #1350 remains the close gate.

Outcome

Establish the authenticated research-state foundation within the existing Project container and sole CURRENT authority. This is a storage primitive, not Branch or Proposal lifecycle implementation.

Acceptance

• Document the required capability/format amendment before implementation, including compatible-reader and producer identity, immutable complete-Version versus projection identity, restoration scope, and separation of frozen research content from later operation/acceptance history. Unsupported formats fail before mutation; no migration machinery.
• Register immutable Version descriptors, context heads, content dependencies and durable operation receipts as authenticated publication participants. Version identity is separate from generation, checkpoint, live handle and package identities. Reject conflicting content under an immutable identity. A projection has separate content/selection identity and source-Version provenance.
• Expose storage operations to register, inspect, and restore an explicitly selected context into new current state, reusing writer locks, complete publication validation and recovery. Preserve unselected context heads and all current history participants. Define the affected Project-level state explicitly.
• Capture research metadata, graph, ontology composition, source/Artifact identities and local change dependencies. Preserve selected local Artifact bytes and report missing/unverifiable external evidence explicitly. No implicit historical fetch.
• Preserve ADR 0018 pre/post-linearization results and exact-request replay; conflicting reuse returns GF_IDEMPOTENCY_CONFLICT. Define and enforce receipt lifetime/resource limits and post-expiry behavior independently of retained accepted-contribution deduplication. Do not inherit checkpoint tombstone expiry implicitly.
• Foundation tests use real storage and explicitly labeled context/head/receipt fixtures: immutable identity conflict, exact historical inspection, selected restoration preserving unrelated state/history, fault/recovery and replay across reopen. Do not present fixtures as real Branch/Proposal proof.
• Establish conservative content roots needed to keep every registered Version valid until B adds selected physical reclamation; A must not claim bounded selected retention or close feat(storage): add immutable research Versions and dependency retention #1350.

Implementation and evidence

Primary homes: graphforge-storage project_generation/project_publication/workspace participants and a research-Version module; existing publication failpoints and filesystem admission. Use current Rust error/receipt conventions with bounded safe causes, no source contents or credentials. Update research-workspaces.md, storage architecture/capability documentation, and the owning TESTING.md rows. Run targeted real-storage tests on an admitted filesystem plus applicable Bazel/CI Gate, formatting and gate-registry checks. Given independently evolving context fixtures, restoring one historical context leaves the others and receipt history intact after reopen. Given a fault before or after CURRENT replacement, recovery and replay truthfully distinguish uncommitted from committed outcomes.

Dependencies and exclusions

Depends on #1346 and #1348 (both closed). #1536 depends on #1535. No Slice evaluation, Branch edits, Proposal review/acceptance, binding wrappers, or portable research import/export.