v0.11.58

Stop the auto-dispatch loop from stalling when the top-ranked
available task is eligible only for an engineer blocked by the
per-engineer release-exclusion (#697) or recent-dispatches map.
In batty-marketing, task #597 (body-owner alex-dev, restricted
via #705 to alex-dev-1-1) sorted first in
available_dispatch_tasks. Alex was inside the 1h release-exclusion
window after releasing the task, so ranked_engineers.find(...)
returned None and the outer loop break'd — leaving idle
priya-writer-1-1, kai-devrel-1-1, and sam-designer-1-1 without
their own body-owned work for 33 minutes until the manager
dispatch-gap intervention's fallback_direct_dispatch kicked in.
The intervention burned manager + architect tokens on every
subsequent poll while masking the root cause.

Fixes

• Defer release-excluded tasks instead of stalling the queue
  (src/team/dispatch/queue.rs) — enqueue_dispatch_candidates
  now tracks eligibility_excluded_task_ids: HashSet<u32> across
  loop iterations, extends unavailable_task_ids with it so the
  blocked task drops out of the next available_dispatch_tasks
  call, and replaces the premature break on empty-engineer-pool
  with insert(task.id); continue;. The loop now advances to the
  next candidate so other idle engineers get their own tasks
  without waiting for the excluded engineer's window to expire or
  for the fallback intervention to fire.
• Regression test
  (enqueue_dispatch_candidates_defers_release_excluded_task_and_dispatches_next_priority)
  — reproduces the batty-marketing shape: two body-owner-routed
  tasks, one owner release-excluded, one idle. Before the fix,
  dispatch_queue was empty; after, the non-excluded owner gets
  their task.