fix: ignore superseded workflow schedule reads

[ooiuuii]

Why

An older schedule-list response can undo a newer acknowledged pause/resume in the Workflows drawer. With two schedules, pause A and delay its subsequent list response; pause B and allow the newer list to render; releasing A's older list changes B's action back to Pause even though a fresh HTTP read still reports enabled=false.

Approach

Give schedule reads a monotonically increasing request ID. Only the latest started request can update schedules or report an error. Invalidate pending IDs when the workspace/enabled effect restarts. One existing hook changes; no API, persistence, polling interval, dependency, or workflow execution changes.

Testing

New validation on 2026-10-09 against main f8f1343:

• RED at 01:18:47 UTC with the actual WorkflowsContent in Chromium and real local Hive HTTP/SQLite, delaying delivery of an unmodified older list response
• GREEN at 01:19:52 UTC; controls cover ordinary resume, obsolete HTTP-error suppression, current HTTP-error visibility, and a pending list across a workspace switch
• pnpm install --frozen-lockfile, pnpm check, pnpm build, web-source TypeScript check and git diff --check passed
• One scoped review of correctness, architecture, evidence and protocol scope found no blockers

The runnable browser diagnostic is retained outside the production diff, following the current UI testing exception. Browser proof mounts the real component with minimal styling and temporary schedules; it does not cover full app-shell navigation, mobile layout, real devices, providers or actual scheduled workflow execution. HTTP 503 controls are explicitly injected; the primary race uses real response bodies.

Whole-project tsc --noEmit reports two TS2352 errors in unchanged tests/unit/workspace-shell-runtime.test.ts (lines 15 and 119). Full pnpm test, server regression suites and packaging were not run for this UI-only change. Existing build/style warnings remain unchanged.