Architecture: all panels must be reactive via centralised Signals — Python Processes timer-polls instead

[MelbourneDeveloper]

The mandate

Per the project architecture (CLAUDE.md): all state that can change uses
Signals for reactivity — no stale state on screen — and all state is centralised
in the single store file. Every panel must subscribe to centralised store
Signals; none may hold its own ad-hoc state or poll on a timer.
([EXTACT-REACTIVE-STATE], #58.)

The violation

The Python Processes panel breaks this. It is the only sidebar tree panel
that does not subscribe to the store's Signals — it refreshes itself on a
2-second setInterval poll:

• process-explorer.ts:442-468
  — wireVisibilityRefresh() → setInterval(() => provider.refresh(), 2000)
  (DEFAULT_REFRESH_MS = 2000). No effect(), no store signal.

Contrast with the two compliant panels:

• Modules subscribes via effect() to store.analysisRevision
  (module-explorer.ts:458-470).
• Basilisk info subscribes via effect() to store.lspState + store.client
  (info-panel.ts:154-161).

The process panel is the odd one out, and the timer is exactly the "stale state /
poll" pattern the architecture forbids.

Secondary: panel-local state is not centralised

Even the compliant panels keep their data in local instance fields rather than
the single store file:

• process-explorer.ts — this.processes, this.fetched, this.sortMode,
  this.groupMode, this.filterText
  (process-explorer.ts:180-185).
• module-explorer.ts — this.modules, this.workspace, this.viewMode,
  this.sortMode, this.filterPattern
  (module-explorer.ts:223-229).

CLAUDE.md: "Each app has a single file for global state. No state should live
outside this file." This mutable view/data state belongs in the store as Signals,
with panels rendering from them — not held privately per provider.

(On-demand webviews — memory-dashboard.ts, memory-ref-graph.ts,
reference-graph.ts — render one-shot snapshots and likewise don't subscribe to
state. Lower priority, but same principle; track here.)

Required fix

• Python Processes must be reactive via centralised Signals, not a timer. Add
  a centralised process-list signal to the store, fed by whatever source drives
  it (the LSP basilisk.profiler.processes round-trip), and subscribe the panel
  with an effect() exactly like Modules/Info. Delete the setInterval poll. If
  the only available source is genuinely a poll (OS processes have no push event),
  the poll belongs in the store updating a signal — not in the panel — so the
  view stays a pure projection of centralised state.
• Move panel-local mutable state into the store as Signals; providers render
  from store signals and own no mutable data of their own.

Cross-references

• Supersedes point Add debug session management, basilisk-common crate, Zed extension, and release pipeline #2 of Python Processes empty state: pointless Refresh button, non-reactive list, and a false "No Python processes running" #147 (that issue is narrowed to the empty-state cosmetics:
  Refresh-button placement and the false "No Python processes running" message).
• [EXTACT-REACTIVE-STATE] (Type Health / Module Explorer panels are not reactive — require manual refresh (centralize state in store via Preact signals) #58), [PROFILE-PROCESSES-PANEL],
  [PROFILE-UI-GATE] — docs/specs/.
• Python Processes is dev/test-gated ([PROFILE-UI-GATE]) today, but the
  architecture conformance must hold before the gate opens.

Acceptance criteria

• No panel uses a setInterval/polling refresh; every panel re-renders from a
  centralised store Signal via effect().
• The Python Processes list is driven by a store signal; the panel holds no
  mutable data of its own and the wireVisibilityRefresh timer is gone.
• Mutable panel/view state (sort/group/filter/data) lives in the store, not in
  provider instance fields.
• An e2e test asserts the process panel updates reactively from store state
  (no timer), cross-referencing the spec ID.

[MelbourneDeveloper]

Fixed (pending PR)

Confirmed there is no OS/LSP push event for process changes (the LSP exposes
only the basilisk.profiler.processes command, no basilisk/processesChanged
notification), so polling is retained — but it is no longer the panel's refresh
mechanism. The poll now messages a centralised signal, and the panel reacts
to it, exactly like the Modules panel reacts to analysisRevision.

Changes

• store.ts — added a centralised processesRevision signal + bumpProcessesRevision().
• process-explorer.ts — the visibility-gated poll and the manual Refresh
  command now store.bumpProcessesRevision() instead of calling provider.refresh();
  the panel subscribes via an effect, so it's a pure projection of centralised
  state and owns no refresh-timer of its own.
• reactive-refresh.ts (new) — extracted the shared subscribeRevision(signal, panel)
  primitive; Modules (analysisRevision) and Python Processes
  (processesRevision) now share one effect-subscription implementation (DRY — the
  duplicated logic that this fix would otherwise have created is merged).

Tests (TDD — written first, confirmed failing on the missing API, then green):

• Python Processes panel refreshes automatically when processesRevision bumps
• bumpProcessesRevision bumps the processesRevision signal

All 6 tests in the [EXTACT-REACTIVE-STATE] suite pass; tsc + eslint clean.

Out of scope (residual): the secondary point — panels still hold their data
in instance fields (this.processes, this.modules) rather than the store — is
unchanged and identical across both panels. Track separately if we want to lift
panel data into the store too; this fix resolves the reactivity violation (timer
poll bypassing Signals).