fix(federation): ensurePeered must not auto-heal needs_attention peers

Discovered during live verification of #10b Scenario 3: the switch
in ensurePeered had no case for needs_attention, so it fell through
to performHandshake. Because the /peer/accept idempotent-200-no-update
safeguard covers needs_attention on the inbound side, the remote
returned 200 without writing the new secret, and performHandshake
transitioned the local peer to 'active' on the 200 response — auto-
healing a state that requires admin intervention.

Affected paths: sendCallRelay non-blocking warm-up (used by typing
relay); any future caller of ensurePeered on a needs_attention peer.
Not affected: resolvePendingPeers (already filters on status='pending').

Fix: explicit case 'needs_attention' returning { status: 'rejected',
error }. Caller observes the rejection and does not advance state.

packages/server/src/utils/federationPeering.ts

@@ -73,6 +73,9 @@ export async function ensurePeered(origin: string): Promise<EnsurePeeredResult>
         // Unreachable peers were previously active — treat as active for peering
         // (the health check will restore them; don't re-handshake)
         return { status: 'active', peerId: existing.id };
+      case 'needs_attention':
+        // Admin intervention required — do not auto-heal via performHandshake
+        return { status: 'rejected', error: 'Peer in needs_attention — admin Reset required' };
       case 'awaiting_approval':
         return { status: 'pending', error: 'Awaiting admin approval on remote instance' };
       case 'pending':