fix(assign): source candidates from full actionable plan, not top-10 triage (#197)

bv --robot-triage is hardcoded to ≤10 recommendations (beads_viewer
triage.TopN), so GetTriageRecommendations(wd, 100) can never surface more than
10 candidates regardless of the count requested. On large or heavily-gated
backlogs whose top-ranked rows are epics / gated / blocked, the assigner
(`ntm assign --watch` / coordinator) finds nothing dispatchable and reports the
queue drained while dozens of beads below the top-10 cut are actually
actionable — silent starvation (#197).

Adds bv.GetActionableRecommendations, which sources candidates from the
FULL dependency-aware actionable set (bv --robot-plan, already wired as
GetPlan) ranked by triage scoring:

  - triage recommendations come first, in triage's scored order — they carry
    the rich BlockedBy/Labels/Status/Score fields the assign filters
    (classifyTriageRecForAssignment) depend on;
  - every actionable plan item triage did NOT surface is appended as a
    synthesized rec, so beads beyond the top-10 are dispatchable. Plan items
    are the dependency-aware actionable set (no BlockedBy), so they pass the
    blocked-by filter and are classified by status/labels/active-assignment
    like any other rec.

Degrades safely: a --robot-plan failure falls back to the (capped) triage set
so callers never regress below today's behavior; a triage failure returns the
error, matching the existing call-site error handling.

Repoints all four assign.go call sites (candidate sourcing, post-completion
unblock check, getBeadBlockers, getBeadTitle) at the uncapped helper so a bead
below the top-10 cut is no longer invisible to assignment or to blocker/title
lookups.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>