fix(compute): show queued jobs on the notebook bar and drain them on restart

[wen2zhou]

Problem

When compute jobs exceed a concurrency limit (session limit or provider ceiling) they enter a
queued status while waiting for a slot. Two gaps made queued jobs invisible and fragile:

1. Invisible on the notebook bar. submitJob only broadcast job-updated for dispatched
   (submitted) jobs; a queued job was written to the DB but never broadcast, so the renderer store
   — which hydrates once then lives entirely off broadcasts — never learned about it. On top of
   that, RemoteJobBadge only counted running/submitted jobs and subscribed to a stable
   selector reference, so it did not re-render on status changes anyway.
2. Orphaned on restart. Jobs queued when the process exited were never re-dispatched on the next
   start, so they sat in queued forever even after capacity freed up.

Proposed change

• Broadcast on create. submitJob now broadcasts job-updated immediately after creating any
  job (queued or submitted), so the renderer sees it instantly. This also closes a brief invisible
  window for submitted jobs before the async dispatcher emits its first transition.
• Show queued jobs. RemoteJobBadge now displays N running · M queued while jobs are queued,
  stays amber (not gray idle), lists queued rows in the tooltip with a literal "queued" label
  (instead of a misleading elapsed time), and carries an accurate aria-label.
• Scoped subscription. The badge subscribes to only its session's job slice via useShallow, so
  a job update in another session no longer re-renders it.
• Drain on startup. New drainQueuedJobs() / drainOnStartup() dispatch queued jobs that can
  now fill free capacity after a restart; wired in ipc.ts right after the poller starts.

Scope and non-goals

• Scope: queued-job visibility on the notebook bar + restart drain, within the existing concurrency
  model (session limit + provider ceiling). No schema changes.
• Non-goals: changing the admission/concurrency logic itself, the global queue limit, or other job
  surfaces (e.g. a full job-list page).

Acceptance criteria and validation

• A queued job appears on the notebook bar immediately (amber, "N queued"), drops from the queued
  segment once dispatched to running, and the badge returns to gray "N jobs" once every job is
  terminal.
• After a restart with free capacity, previously-queued jobs are dispatched.
• npm run typecheck, npm run lint, npm run test all pass (full suite: 5795 passed, 0 failed).
• Tests: 16 RemoteJobBadge render tests, a queued-broadcast integration test, a drainOnStartup
  unit test + a multi-job "drain up to ceiling" unit test, and a restart-drain integration test
  (the latter now polls instead of a fixed delay to avoid CI flake).

Review focus

• compute-service.ts — broadcast-on-create placement and the drainQueuedJobs facade.
• RemoteJobBadge.tsx — useShallow session scoping and the segments / aria-label logic.
• concurrency-manager.ts — drainOnStartup (delegates to tryDispatchNext, which already
  iterates the whole queue under the shared admit lock).