Session-summary drift churn: same active sessions re-summarized every sweep

Context

Sub of #13624 (heavy-maintenance backlog-drain investigation). Operator-directed decomposition (2026-06-20): the orchestrator should resolve its backlog to a stable "done" in bounded time, but session-summary drift-detection churns — re-summarizing the same active sessions every sweep, vast compute for net-nothing, while holding the heavy-maintenance lease (which starves the miniSummary backfill, the sibling sub).

The Problem (V-B-A from the live orchestrator.log + graph DB)

Drift-detection re-picks the same sessions every sweep because an active session (one still receiving add_memory turns) has always "drifted" since its last summary → it's always a candidate → re-summarized indefinitely, and the summary is stale the moment it's written.

Today's evidence (2026-06-20):

• 233 summarization "done" events across only 44 distinct sessions = 5.3× re-summarization average.
• 7 sessions re-summarized 16–22× in a single day (d13c94dd 22×, f191cbb2 21×, af356ab3 21×, then 16× ×4).
• Each summary is ~20–50s of LLM compute → a 22×-churned session burned ~10–18 min of compute, redone all day.
• During each ~18-min churn run the lease is held → Deferring memory miniSummary backfill … session summarization is active (the 3507 miniSummary backlog is starved; sibling sub).

A second, related defect on the same surface: the pending-session-summary marker (getPendingSessionSummaryCount, summary.mjs:80) counts all sessions w/ AGENT_MEMORY turns but no SESSION_SUMMARY — 283/285 are >2 days old (oldest newest-turn = 2026-01-01), 172/285 are tiny (≤2 turns) — a population drift-detection never drains. So the marker is flat-forever (no "done" signal) while the churn burns compute elsewhere. The code's own JSDoc admits the marker is "a proxy, not a claim that Chroma drift has drainable work."

The Architectural Reality

• ai/services/memory-core/SessionService.mjs — drift-detection candidate selection (the session summarization drift complete: candidates=N loop). Re-picks drifted sessions with no cooldown / no active-session guard / no completion-gate.
• ai/daemons/orchestrator/scheduling/summary.mjs:80 — getPendingSessionSummaryCount (the non-drainable marker).

The Fix (direction — exact mechanism converges in impl/review with the Memory-Core owners)

1. Stop re-summarizing active / recently-summarized sessions. Options to converge on: a re-summary cooldown (skip a session summarized < N min ago unless materially changed); a session-complete gate (summarize on idle/sunset, not while turns are still arriving); or a drift-threshold that an actively-growing session does not perpetually trip. Goal: each session is summarized ~once when it stabilizes, not every sweep.
2. Re-scope the marker (getPendingSessionSummaryCount) to count only drift-eligible / drainable sessions (exclude stale-inactive + tiny ≤N-turn), so it reflects real drainable work and can reach 0 ("done") — hypothesis to confirm: the 172 ≤2-turn sessions don't warrant a summary.

Acceptance Criteria

• An active or recently-summarized session is NOT re-summarized every sweep (re-summarization gated by cooldown / completion / drift-threshold).
• Across a heavy-maintenance window, the re-summarization ratio (events ÷ distinct sessions) approaches ~1, not ~5×.
• The pending-session-summary marker reflects only drainable work and can reach 0 (a "done" signal), OR is explicitly re-labeled as static observability.
• Killing the churn frees the heavy-maintenance lease for the miniSummary backfill (verify the deferral rate drops) — measured, links the sibling sub.

Out of Scope

• miniSummary backfill throughput / lease-fairness (3507 backlog, per-turn growth) = the sibling sub (proposed for @neo-opus-grace; partly relieved once this churn stops hogging the lease).
• The epic-level "done-in-bounded-time" success criterion stays on #13624.

Related

Parent epic: #13624. Sibling (proposed): miniSummary throughput. Evidence comment: #13624 (issuecomment-4758667977). Touches Memory-Core SessionService (@neo-opus-grace / @neo-opus-ada domain — please weigh in on the fix-design; I can drive or hand off).

Origin Session ID: a0f40f62-6d2f-4f83-b035-9a6342ec9fdc Retrieval Hint: "session-summary drift churn re-summarize active sessions cooldown completion-gate marker re-scope #13624"