fix(1025): gate auto-block counter on mergemaster presence

1018's merge_failure_block_subscriber counted every MergeFailure transition
toward the 3-strike block threshold, but mergemaster's recovery iterations
(squash → fail → fix → retry) emit multiple MergeFailure transitions while
making real progress. Story 997 was blocked at 10:59:46 while mergemaster
was still resolving conflicts and would have succeeded a minute later.

Fix: pass the AgentPool to the subscriber. When a mergemaster agent is in
the pool for the story, MergeFailure transitions are recovery iterations
in progress and do NOT increment the consecutive-failure counter. Block
only fires for the genuinely-stuck case (no recovery agent attached and N
consecutive failures accumulate).

Tests:
- mergemaster_running_suppresses_block: 3 failures with recovery_running=true
  → counter stays empty, story stays in MergeFailure
- no_mergemaster_still_blocks_at_threshold: 3 failures with recovery_running=false
  → blocks (1018 behaviour preserved)

All 2938 tests pass.

server/src/startup/tick_loop.rs

@@ -69,8 +69,13 @@ pub(crate) fn spawn_event_bridges(
         );
 
         // Consecutive-failure auto-block subscriber: blocks stories after N
-        // consecutive MergeFailure transitions (story 1018).
-        crate::agents::pool::auto_assign::spawn_merge_failure_block_subscriber(root.clone());
+        // consecutive MergeFailure transitions (story 1018).  Bug 1025: takes
+        // the agent pool so it can gate the counter on mergemaster presence —
+        // failures during active recovery iteration do not count toward block.
+        crate::agents::pool::auto_assign::spawn_merge_failure_block_subscriber(
+            Arc::clone(&agents),
+            root.clone(),
+        );
 
         // Content-store GC subscriber: purges all ContentKey::* entries for a
         // story when it reaches a terminal stage, preventing zombie entries from