feat(smithy,smithy-web): dispatch stuck-queue warning (#59)

[komoreka]

Internal review PR before opening upstream against stoneforge-ai/stoneforge.

Summary

Closes upstream stoneforge-ai#59. Surfaces a clear signal when the dispatch worker queue is stuck (ready unassigned tasks > 0, no available workers). Three surfaces:

• CLI log: per-tick warning [dispatch] N task(s) ready, no available workers..., rate-limited to once per 20 ticks (configurable via DispatchDaemonConfig.stuckWarnTickInterval), re-warns immediately after the queue clears and re-stuckens.
• HTTP: GET /api/daemon/status now includes a health field with { readyUnassignedTasks, availableWorkers, stuck, hasStuckQueue, computedAt }.
• smithy-web: a yellow DispatchHealthBanner on the agents and workspaces pages when hasStuckQueue is true. Dismissible per page-load.

The model is intentionally simple: existing dispatch logic does not route by role at the data layer (assignTaskToWorker in dispatch-daemon.ts:2705 grabs the first unassigned task without filtering by role), so the stuck-queue concept is exclusively about workers. Directors are interactive (humans drive them); stewards run on triggers; neither pulls from the unassigned queue. An "available worker" is one that is registered, not disabled, and not terminated. At-capacity workers do not count as stuck (the queue is busy, not stuck) to avoid misleading warnings.

Validation

• bun test src/services/dispatch-daemon.bun.test.ts covers four detection cases (no tasks, no workers, available worker, disabled worker) plus the warn-on-tick test. 1549 pass / 0 fail in smithy.
• vitest src/server/routes/daemon.test.ts covers status payload with daemon, without daemon, and with getDispatchHealth throwing. 42 pass / 0 fail in routes suite.
• NODE_ENV=development npx turbo run typecheck passes (16/16 packages).
• NODE_ENV=development pnpm build passes (13/13).
• Manual smoke pending (do this in cloudboostup-website before opening upstream PR).

Cross-PR dependency note

This branch contains a 5-line type addition (disabled?: boolean on BaseAgentMetadata) and a 10-line file (isAgentDisabled / isAgentEnabled helpers) that overlap with PR stoneforge-ai#60 against upstream. The duplication is byte-identical (verified during Task 1 review); when PR stoneforge-ai#60 merges first the rebase here is trivial.

Out of scope

• Pool-routing follow-up (filed as a separate upstream issue per @notadamking's split-out request).
• Per-role health for directors/stewards (dispatch doesn't route by role, so the concept doesn't apply).
• V2 placement-blocker design (PRD PRD: Stoneforge V2 first slice stoneforge-ai/stoneforge#64 slice 19) — this PR addresses the V1 surface.

Manual smoke recipe

cd /Users/adriankomorek/git/github/CloudBoostUP/cloudboostup-website
sf agent disable <some-worker-id>
sf task create --title "stuck-queue smoke test" --priority 2
kill \$(lsof -ti :3457) 2>/dev/null
sf serve smithy
# Expect: within ~10s, log line "[dispatch] 1 task(s) ready, no available workers..."
# Hard-refresh http://localhost:3457/agents — yellow banner appears.
sf agent enable <id>
# Expect: banner clears within ~5s, log line stops.
sf task close <task-id>