perf(frontend): centralize live process polling ownership (#1941)

`useProcessInfo` shared its result through a Jotai atom, but every hook
consumer started its own initial request and three-second interval. The
default dashboard mounts several consumers (CPU card, Live Process Table,
hardware report export), so the same `get_process_list` IPC ran as several
concurrent polling loops writing to one atom.

Give the shared live process resource one polling coordinator per Jotai
store, implementing the lifecycle decided in ADR 0013:

- Consumers register demand while mounted and enabled; the first starts
  polling and the last stops it.
- Polling pauses while the document is hidden and refreshes immediately on
  becoming visible again.
- Only one request may be in flight: periodic ticks during a slow request
  are skipped (not queued), and demand signals are coalesced through a
  microtask so StrictMode remounts and visibility flaps produce one request.
- A generation counter keeps a response from a stopped or superseded
  lifecycle from overwriting current state.
- The last successful list survives a transient failure, which reports
  through one shared error path instead of once per consumer.

The tests are rewritten against this contract (11 cases: shared schedule,
enabled transitions, visibility, slow requests, stale responses, cleanup)
and now mock `ProcessInfo` with its real string-typed usage fields.

Closes #1931