Fixes #18264

Problem

When runSubagentAnnounceFlow repeatedly returns false (deferred), finalizeSubagentCleanup resets cleanupHandled = false and removes the entry from resumedRuns, allowing retryDeferredCompletedAnnounces to pick it up again immediately. If the underlying condition persists (stale registry data, transient state after cron deletion), this creates an infinite loop delivering 100+ announces over 3+ hours.

The loop persists even after the originating cron job is disabled/deleted, because the subagent registry is persisted to disk and restored on gateway restart.

Root Cause

In subagent-registry.ts, finalizeSubagentCleanup():

if (!didAnnounce) {
  entry.cleanupHandled = false;    // allows retry
  resumedRuns.delete(runId);       // allows resumeSubagentRun to fire again
  // No limit on retries -> infinite loop
}

Fix

1. Max retry count: Track announceRetryCount on SubagentRunRecord. After MAX_ANNOUNCE_RETRY_COUNT (3) failed attempts, mark as completed.
2. Expiration: Announce entries older than ANNOUNCE_EXPIRY_MS (5 min since endedAt) are force-expired in both resumeSubagentRun and retryDeferredCompletedAnnounces.
3. Persistence: Both new fields (announceRetryCount, lastAnnounceRetryAt) persist to the registry, surviving gateway restarts.

Testing

• All 10 existing tests pass (nested, steer-restart, including the 'retries deferred parent cleanup' test)
• 2 new regression tests added for the loop guard
• 3 announce-queue tests pass

Greptile Summary

This PR adds loop-guard protections to the subagent announce retry mechanism to fix an infinite retry loop (#18264). When runSubagentAnnounceFlow repeatedly returns false, the code now tracks retry attempts (announceRetryCount) and enforces both a max retry count (3) and a time-based expiry (5 min since endedAt). Guards are added at three points: resumeSubagentRun, finalizeSubagentCleanup, and retryDeferredCompletedAnnounces.

• Max retry + expiry guards: Well-placed at all three entry points that could re-trigger the loop, with consistent logic and persistence across restarts.
• Bug: replaceSubagentRunAfterSteer does not reset announceRetryCount/lastAnnounceRetryAt when creating a replacement run — a steered replacement could inherit an exhausted retry budget and be immediately force-expired.
• Tests: Two new regression tests verify field persistence and entry skipping, though test coverage for the finalizeSubagentCleanup retry-counting path would strengthen confidence.

Confidence Score: 3/5

• The core fix is sound but has a bug in the steer-restart path that could suppress announce delivery for replacement runs.
• The main loop-guard logic is correct and well-structured, with guards at all three re-entry points. However, replaceSubagentRunAfterSteer not resetting the new retry fields is a real bug that could cause steered replacement runs to silently lose announce delivery. This is the same category of issue (silent announce loss) that the PR is trying to fix.
• src/agents/subagent-registry.ts — the replaceSubagentRunAfterSteer function needs to reset announceRetryCount and lastAnnounceRetryAt on the replacement record.

_{Last reviewed commit: efe0541}