Seed: redeploy a workflow orphaned by a stack restart, don't skip it

[TheGreatAxios]

Summary

A dev-stack restart permanently strands every previously-deployed
workflow: workbench seed sees the workflow_run row still reading
deployed and skips it, then fails on the one step that could have
fixed it — a 409 not routable from the sidecar-mail trigger, with
advice ("wait for the sidecar to connect") that's already false, since
a sidecar is connected. It's just not the one that row is bound to.

Mechanism (confirmed by reading apps/hub/src/index.ts's
sidecar router construction, vendor/intx/hub-sessions's
sidecar-handler.ts, and a live Postgres read): a shared-placement
workflow_run never populates its sidecar_id column — the only
thing binding an address to a live process is sidecarRouter's
in-memory addressIndex, populated when a sidecar connection proves
ownership over its websocket. That table lives in the hub process
only; a hub/sidecar restart empties it while the DB row keeps reading
deployed forever. Verified against the live fixture
tnt_4799af5615d7fa0eb995c224bc99253a / run
run_6d952fb4a6a85fa6feee7f3af25a3908: status='running',
sidecar_id NULL.

Fix: ensureDeployment (packages/hub-client/src/seed.ts) now
checks GET /api/tenants/:tenantId/workflows/runs/:runId/health (a
live read of the routing table) before skipping an already-"deployed"
row, and pushes a fresh deployment instead when it isn't routable.

Redeploy, not rebind: a shared sidecar carries no durable
per-run state of its own, so handing an old run's identity to a
newly-connected sidecar process would misrepresent what survived the
restart. The stale row is left in place (not deleted/rebound);
POST .../workflows/deployments already mints a brand-new
workflow_run unconditionally, so this needed no new hub-side
endpoint — only a live check before the CLI's own skip decision.

Builds on #283 (seed idempotency on skill-name conflicts) and #284
(package version bumps) — same family of "partial or stale state with
no repair path."

Not in this PR

• Live restart-and-reseed verification against a real running dev
  stack — not done here since the task explicitly ruled out
  booting/binding the stack on :3000. Verified instead via the live
  Postgres read above, an authenticated-boundary curl (401, not 404)
  confirming the new health route is mounted correctly, and a red/green
  unit test that reproduces the exact trap against pre-fix code.
• Cleanup of the orphaned row itself — it's left dangling in the DB
  after a fresh deployment replaces it; low-risk since the health check
  now excludes it from future skip decisions, but worth a follow-up if
  stale rows accumulate visibly.

CL-6577

Test plan

• bun test packages/hub-client — 164 pass
• tsc --noEmit in packages/hub-client — clean
• eslint on touched files — clean
• New test fails against the pre-fix code (verified via temporary revert), passes after
• Live Postgres read confirms the exact mechanism against the reported fixture
• Unauthenticated curl against the live dev stack's new health route returns 401 (route exists), not 404