Persist Libra-native code version anchors for Agent runs

[Anduin9527]

Context

Libra Code persists Agent development history as Intent, Plan, Task, Run,
PatchSet, and Decision objects. The Memory work in #456 compiles terminal Tasks
into Episodes and uses code versions to decide whether an Episode applies to the
current checkout.

Each Episode needs two code anchors:

• base_oid: the Libra code version where the Agent run started;
• result_oid: the durable Libra code version produced by the run.

Current behavior

The existing persistence path resolves the run base with git rev-parse HEAD.
Libra stores its own refs in the repository SQLite database, and a valid Libra
repository may have no .git directory. A failed Git lookup currently becomes
the zero OID, so a run can lose an existing Libra HEAD.

The final Decision path also writes result_commit_sha: None. Memory can still
compile and inspect the resulting Episode, but the applicability check cannot
reliably place that Episode in the current code history. It is therefore omitted
from normal context recall.

flowchart LR
    H["Libra HEAD"] -->|run starts| B["Run.base_commit_sha"]
    B --> A["Agent execution"]
    A --> C["accepted code state"]
    C --> D["Decision.result_commit_sha"]
    B --> E["Episode.base_oid"]
    D --> F["Episode.result_oid"]
    E --> G["version applicability"]
    F --> G
    G --> R["Memory recall"]

Loading

Proposed contract

1. Resolve the start anchor from Libra's repository HEAD through the existing
   history database connection.
2. Record the result anchor after accepted changes become a durable Libra code
   version.
3. Keep Run.base_commit_sha and Decision.result_commit_sha as the
   authoritative fields; Memory derives base_oid and result_oid from them.
4. Treat an unborn branch as an explicit repository state. Missing or corrupt
   Libra HEAD data should return an actionable persistence error.

The existing fields appear sufficient, so this can be implemented without a new
database service or a separate Memory-owned version store.

Questions

1. Which runtime component should create or report the result code version?
2. Should an accepted code-changing Agent run create a Libra commit
   automatically, or should the execution layer provide an already-created OID?
3. What should result_commit_sha contain for read-only, failed, or cancelled
   runs: the base OID or no value?
4. How should isolated worktree execution publish its accepted result into the
   repository history?
5. Does a checkpoint only preserve Agent context, or can it also identify a
   durable code version?

References

• RFC: Add version-aware M2 Episode memory for Agent development history #451
• feat(memory): add version-aware development history core #456
• src/internal/ai/orchestrator/persistence.rs
• src/internal/ai/memory/applicability.rs