Split hosted memory by branch and security domain

[romgenie]

Local source: coven-code/issues/04-split-memory-by-branch-and-security-domain.md

Summary

Hosted review memory needs branch and security-domain segmentation. Memory learned from main can be wrong on a release branch, and security-sensitive reviews should not feed ordinary review memory.

Current Evidence

• session_storage::TranscriptMessage records git_branch.
• Memory pathing in memdir.rs and team memory sync does not include branch, visibility, or security domain.
• Auto-extracted memories are appended to .coven-code/AGENTS.md without branch-specific targeting.

Problem

One repo can have multiple active truth domains:

• main
• release branches
• long-lived feature branches
• fork PR heads
• security advisories
• private incident branches

Using one repo-wide memory pool for all domains can cause stale or sensitive facts to influence unrelated reviews.

Proposed Design

Add a memory domain layer:

pub enum MemoryDomain {
    DefaultBranch,
    Branch { name: String },
    Release { name: String },
    PullRequest { number: u64 },
    SecurityPrivate,
}

Hosted mode should load memory in a controlled order:

1. Tenant/install policy.
2. Repo-wide stable memory.
3. Domain-specific memory.

Fork PR input should normally be session-only and not durable unless approved.

Acceptance Criteria

• Hosted memory paths include a domain component.
• Default branch memory is separated from PR/fork/security memory.
• Security-domain memory is never loaded into public PR review jobs unless explicitly allowed.
• Tests prove branch-specific memory does not leak into default-branch reviews.
• Tests prove security-domain memory is excluded from normal public reviews.
• Review artifacts record which memory domains were loaded.

Open Questions

• Should release branches inherit from default branch memory by default?
• Should PR-specific memory expire automatically when the PR closes?
• How should renamed branches map to existing memory?