Python Processes empty state: pointless Refresh button, non-reactive list, and a false "No Python processes running"

[MelbourneDeveloper]

Summary

The Python Processes panel's empty state has three coupled defects:

1. It shows a Refresh button in the empty welcome view, where it makes no
   sense.
2. The list should be reactive (Signals-driven, centralised state) so a manual
   Refresh button is unnecessary at all; while it isn't, the refresh affordance
   should sit next to the process list, not float in the empty state.
3. The message "No Python processes running" is a lie — the list is empty
   because processes are being hidden / the fetch didn't populate, not because
   zero Python processes exist. (Note the status bar in the repro: TMC:
   Disconnected.)

1 — Hide the Refresh button in the empty state (do this now)

The welcome view renders a [Refresh] action
(package.json:84-87,
basilisk.refreshProcesses registered at
process-explorer.ts:406). But the
panel already auto-refreshes on a timer and the welcome copy itself says "The
list refreshes automatically" — so a manual Refresh in the empty state is
redundant and self-contradictory. Hide it here for now; it only makes sense
once there are processes to refresh.

2 — The list isn't reactive; it's timer-polled

The panel is refreshed by a 2-second setInterval, not by the centralised store
signals:

• process-explorer.ts:442-468
  — wireVisibilityRefresh() runs setInterval(() => provider.refresh(), 2000)
  while visible (DEFAULT_REFRESH_MS = 2000).

This is the opposite of the Modules panel, which refreshes off the store's
analysisRevision signal via an effect ([EXTACT-REACTIVE-STATE], #58). Per the
project principle (panels must be reactive via Signals; all state centralised),
the process list should update without a manual button. Until it is genuinely
reactive, the refresh control belongs inline next to the process list (a
view-title or item action on the populated state), never as a lone button in the
empty view.

3 — "No Python processes running" is misleading

fetchProcesses() swallows any LSP error into an empty list and marks the fetch
done, so an errored or not-yet-loaded state renders identically to a genuinely
empty one:

• process-explorer.ts:230-234
  — empty processes → empty tree → the welcome's "No Python processes running".
• process-explorer.ts:305-309
  — on fetch failure: this.processes = []; this.fetched = true; (error logged,
  but the UI asserts the definitive negative).

So when the LSP is disconnected / still starting / the feature is gated, the panel
claims there are no processes rather than admitting it couldn't load them.
This is the same trust-breaking false-negative as #144 ("No Python files found"
during startup): the empty message must distinguish loading / couldn't load /
unavailable from genuinely zero processes, and only assert the latter once a
fetch has actually succeeded.

A static viewsWelcome can't express those states — drive the empty/loading/error
copy from centralised store state (a basilisk.processesState context key gating
multiple viewsWelcome entries, or a Signals-driven treeView.message / leading
tree item), so it's never stale and never lies.

Notes

• Entry point is ahead of main. The repro's welcome ("No Python processes
  running. The list refreshes automatically." + three buttons: Run & Profile CPU,
  Run & Track Memory, Refresh) does not match the current tree's
  viewsWelcome (package.json:84-87,
  which has different copy and buttons). Reconcile the committed welcome with the
  running build (same note as "Run & Track Memory (Current File)" dead-ends: toast says "take a snapshot", but stopping produces no chart/trace/report #146).
• Python Processes is behind the dev/test UI gate
  ([PROFILE-UI-GATE]; view when: basilisk.hasWorkspace && basilisk.profilingEnabled, package.json:67-71),
  so this is not shipped-user-facing yet — but the empty/loading honesty must be
  fixed before the gate opens.

Spec / cross-references

• [PROFILE-PROCESSES-PANEL], [PROFILE-UI-GATE] — docs/specs/LSP-PROFILING-SPEC.md.
• [EXTACT-REACTIVE-STATE] (Type Health / Module Explorer panels are not reactive — require manual refresh (centralize state in store via Preact signals) #58) — the reactive-via-Signals pattern this panel
  should follow.
• Sibling of Modules panel falsely shows "No Python files found" while the analyzer is still starting up #144 (the analogous false "No Python files found" empty-state lie).

Acceptance criteria

• No standalone Refresh button in the empty/welcome state; refresh (if kept at
  all) lives next to the populated process list.
• The process list updates without manual refresh, driven by centralised store
  state rather than an ad-hoc panel-local timer.
• "No Python processes running" appears only after a fetch has actually
  succeeded and the count is truly zero; loading / disconnected / unavailable
  states say so honestly.
• The committed viewsWelcome matches the running entry point; an e2e test
  cross-references the spec ID.

[MelbourneDeveloper]

Scope note: the reactivity / centralised-state concern (point #2 above — the panel timer-polls instead of subscribing to Signals) has been promoted to its own first-class architecture bug in #148. This issue (#147) is now scoped to the empty-state cosmetics only: hiding the standalone Refresh button and fixing the false "No Python processes running" message. The Signals/centralised-state fix is tracked in #148.