fix(panel): refresh an extension tab when the panel comes back

[hiskudin]

Two reasons an extension tab showed stale numbers until something was pressed.
Both found while chasing a report that the Derby needed a manual refresh after
opening it, and both confirmed with a spawn probe on the installed extension
rather than by reading.

Reopening the panel wasn't an "open"

The panel is ordered out, not torn down, so its SwiftUI tree survives being
hidden and ExtensionTabView.onAppear — the only caller of tabAppeared —
never fires again. Coming back to a tab you were already on therefore didn't
count as opening it, and the pane kept whatever it last fetched.

The 30s schedule usually covered this within a tick, which is why it read as
intermittent. It isn't covered at all for an extension that declares onOpen
with no intervalSeconds — docs/extensions.md says onOpen means "fetch
when the tab is opened", and that extension would have stayed frozen
indefinitely after the first hide. There's a test for exactly that case.

Showing the panel now counts as the tab appearing, with a floor at the
manifest's own minimumIntervalSeconds so toggling the panel can't spawn a
script faster than polling is allowed to.

The footer's action hints weren't buttons

The pane is keyboard-driven by design, but it renders each action with its key
cap — which reads as a control. So it gets clicked, nothing happens, and a
refresh arriving on the poll a few seconds later looks like the click having
worked. That is precisely how this was reported.

The probe settled it: three invocations, not one carrying --action.

15:36:17 argv=[]     opening the tab
15:36:57 argv=[]     the 30s poll

They're buttons now, disabled while a fetch is in flight, and each is paired
with the row a keypress would have sent. ExtensionHost.resolve reads a row
action as belonging to the selected row and a document action as belonging to
none, so the footer has to agree — otherwise a document action would spawn
--action refresh --row h1 for a row the action was never about. Tested.

Verification

Probe on the installed extension before and after. Before: opening the panel
onto the tab produced no spawn. After: it spawns on arrival and the pane fills
without a keypress, with no polling at all while the panel is hidden — which
is whileFocusedOnly working as intended.

1213 tests pass.