feat(core-status): let the Problems tab act on what it is showing

[guyverino]

What & why

MoonBot's own Problems window carries "reset all" and "refresh". This tab had
neither. It had a channel test and a clear, both gated on the operator having
hand-picked exactly one core in the panel's core selector — a gate that is
permanently shut on every workspace-owned panel, because Auto pins its scope and
renders that selector read-only, so the retained Classic pick can neither be set
nor cleared there. Both buttons therefore read as always greyed, which is how
this started.

Three buttons now, and ONE rule behind all of them. A clicked finding narrows
them to its core; no click means the panel's whole scope. That is this panel's own
convention for a bulk command — the same "the selection when the operator has made
one, the displayed scope otherwise" the footer's fleet update already obeys. The
scope itself is still set where it always was, the core selector in Classic and the
workspace in Auto, so no button carries a private notion of which cores it means.

Refresh is not decoration, and the reason is not obvious. The protocol has no
request for a diagnostics list: a core pushes one on connection and again when its
detectors change it, docs/problems.md says outright that "there is no periodic
diagnostic-list refresh", and the only client command that yields a fresh list is
the destructive clear. But moonproto mutates its retained problems through three
paths and only two raise an event this feed can follow. The third is the
hard-session reset — on a ServerToken or peer-app-token CHANGE, i.e. a hard
reconnect or the MoonBot process restarting behind the same endpoint,
events/active.rs assigns settings.problems = Default::default() and publishes
nothing. The terminal never respawns its feed thread for that, so its store keeps
serving the findings of a core instance that no longer exists, with supported
still true. A restarted core normally pushes a list within seconds and repairs it;
a core too old for the extension never does. CoreCmd::RefreshProblems re-reads
what the library holds now and publishes it — usually identical and dropped by the
store, and after a silent reset the honest "this core has told this connection
nothing".

Notable decisions

• The pick is a CORE, never the clicked row index. The finding list is rebuilt
  from live core data on every repaint, so an index outlives the row it named: one
  finding appearing or clearing above it re-points it at a different core, and the
  reset it narrows cannot be undone. The click resolves its index against the list
  it was drawn from, while that list is still the one on screen. Clicking any row of
  the picked core clears the pick — a narrowing that cannot be undone would strand
  the operator on one core.
• The table keeps its DEFAULT selection mode. Taking the click through
  controlled_row_selection also hands the caller the row highlight and returns
  early from the table's entire keyboard block (data_table.rs:1100), which costs
  up/down/home/end navigation in a table that is read far more than it is clicked.
  The highlight is set per row from the picked core instead.
• "Reset", not MoonBot's "Reset all". Their window belongs to one core, so
  "all" there means all of that core's findings. This tab spans a fleet, where the
  same word reads as "all cores" — a lie the moment the operator has clicked one.
• The blast radius is stated before the press, not after. The tooltip carries
  the count, the confirm names the cores through the same non-truncating list the
  footer's fleet confirm uses, and the outcome reports the shortfall — "reached 9 of
  12" rather than a success toast over a partial result.
• A pick is dropped the moment the surface can no longer show it. Clicking a row
  of its core is the only gesture that clears one, so a pick whose findings have all
  gone — reset on the core, or supported flipped back to unknown — would sit there
  narrowing an irreversible action with nothing on screen saying so. It is checked
  against the DRAWN rows, so the 500-row cap cannot strand one either.
• The table is left with no selection of its own. Its row and cell cursors are
  cleared on every pick change: left behind they paint a second highlight from a raw
  row index (data_table.rs:1231, and the cell background at :1262 paints whether
  or not cells are selectable), and an index is exactly what the pick exists to
  avoid. select_row(None) alone is not enough — it leaves selected_cell behind.
• Two refusals, not one. "The core you clicked is down" and "nothing in this
  scope is connected" have different remedies, and a scope full of live cores must
  never be reported as offline because one picked core is not.
• The request joins the event gate rather than branching beside it. Both reasons
  read the same retained state through the same projection, so
  convert::snapshot_when carries the chain settings_event_snapshot already used
  and the tenth publish block in that loop is not a copy of the other nine.

Known limitations

• The synthetic core swallows both new commands (feed/synth.rs has a catch-all),
  so the tab is inert under --fixture. Nothing there reports diagnostics anyway.
• A reset reaches only the connected cores of a scope. The confirm's count states
  how many that is, but its text does not spell out that offline members were
  dropped.
• Escape is deliberately left alone: it already carries a window-level meaning here
  (it closes an open chart), and a second one on the same key risks swallowing that.
  The pick is cleared by clicking its row again.
• A refused reset or re-read reaches only the log; no strategy or diagnostics
  command has a result path back to the window today.

How to verify

cargo build -p moon-ui-gpui --bin moonterminal --target x86_64-pc-windows-msvc --all-targets
cargo fmt --all -- --check
cargo clippy -p moon-ui-gpui --bin moonterminal --target x86_64-pc-windows-msvc --all-targets -- -D warnings
cargo test --workspace --target x86_64-pc-windows-msvc

Green on the rebased tree: moon-core 1654, moon-ui-gpui 1500 + 320
(theme_contract), fmt clean. Clippy reports 78 findings on this tree and none in
any file this change touches — too_many_arguments on drain_commands already
fired at 12 arguments on origin/main, verified against the base file. FireTest not
run: this change touches neither chart, render, windows nor input.

By hand, on a fleet whose cores report diagnostics: click a finding and confirm all
three buttons narrow to its core and its rows highlight; click it again to widen
back to the scope; check the arrow keys still walk the table; reset one core and
watch its rows go when the core's next list arrives.