Mirror recovery reports blocking collisions one at a time and competes with background sync

[callumalpass]

Problem

A reported hosted-mirror recovery required repeatedly removing a differing local definition and retrying enrollment before the next collision appeared. Later, record conflict resolution returned mirror_busy while a background sync pass processed pending work.

Reported with Linux desktop 0.1.0-beta.100. This is a recovery UX report supported by code inspection, not an independently reproduced deadlock.

Evidence

At 21d035cc:

• crates/connect-mirror/src/sync_inspector.rs collects local_collision issues during initial/rebuild inspection when local and remote exact objects differ without a baseline. Resource collisions are blocking; writable-record collisions need not be.
• crates/connect-mirror/src/directory_sync.rs returns the first blocking issue, despite inspection collecting multiple issues.
• crates/connect-agent/src/mirrors/commands.rs::resolve uses the same exclusive operation guard as synchronization.
• crates/connect-agent/src/mirrors/synchronization.rs::begin_operation_named returns mirror_busy if that guard is held.

Removing/re-adding a mirror discards its comparison baseline, so even valid records can conflict. The exact-object collision message is not evidence of invalid status values or a grammar-revision failure.

Expected outcome

• Surface all known blocking enrollment collisions together, including resource/configuration paths, without requiring destructive retry-and-discover cycles.
• Make conflict resolution usable while background synchronization is active, with clear progress/retry or safe serialization rather than repeated unexplained busy failures.
• Preserve exact-object/revision checks and explicit user decisions; do not introduce an unconditional overwrite/reset bypass.
• Cover multiple simultaneous resource collisions and resolution during an active sync in tests.

Scope

Investigate the recovery interaction before deciding whether bulk resolution is needed. No claim that the reported queue was permanently deadlocked. Authority-transfer fencing is separately tracked in #345.