feat(tui): the keybar reflects the focused workspace pane

[jinyeow]

Why?

Issue #19 turned out to be five-sixths already shipped. Walking its six acceptance criteria
against the tree found five implemented and tested under #48/#49 (ADR 0024, released in v0.4.0) —
the ticket was simply never closed. One sub-clause was genuinely missing:

the keybar reflects the focused pane

It didn't, and it couldn't have: KeybarFormatter.Render was called with ActiveScope (derived
only from ShellViewModel.ActiveSection) and PreviewVisible. WorkspaceViewModel.FocusedPane
never reached it.

Chasing that turned up a second defect the ticket never named: Dispatch's
ApplyWorkspaceFocus arm moved focus without calling RefreshChrome, so even a focus-aware
formatter would have kept painting the previous pane's keys until some unrelated event repainted
the bar.

	before	after
preview focused, what j/k do	scroll the preview	scroll the preview
preview focused, what the bar says they do	j/k:move	j/k:scroll
preview focused, C-h back to the list	unadvertised	C-h:list
bar after pressing Tab	stale — never repainted	repainted

+9 tests (1,409 → 1,418) for ~36 changed source lines. The cost is one new required parameter on
KeybarFormatter.Render and 13 call-site updates in its tests.

Closes #19.

What changed

• App/KeybarFormatter.cs — Render takes a required WorkspacePane focusedPane. Required, not
  defaulted, matching the existing reasoning on previewVisible: advertisement must not be able to
  drift from behaviour because a caller forgot to say which state it is in.
• App/CobaltShell.cs:349 — RefreshChrome() in the ApplyWorkspaceFocus arm. SetIfChanged
  makes it a no-op when the text is unchanged.

Why only those two entries change

ShellCommandRouter.VerbKind:131-149 never branches on FocusedPane — only on the active section.
So o:open, c:comment, v:vote, q/h genuinely behave identically in both panes and are
deliberately left alone. C-h earned a conditional entry because WorkspaceViewModel.FocusLeft:46-54
is a no-op when the list already holds focus, so advertising it unconditionally would be a false hint.

Verification

The shell-level test is the real proof of the criterion:
The_Keybar_Reflects_The_Focused_Pane — RED because after a Tab keypress moved FocusedPane to
Preview, KeybarText still read j/k:move.

All 13 existing KeybarFormatterTests call sites gained the new argument; no assertion was
changed. Clean Release build, 0 warnings / 0 errors; 1,418 tests (391 Core + 1,027 Tui).

Known, not fixed here

Whenever the preview shows, the bar renders Tab:tab (the dead NextTab) alongside
Tab:switch list / preview — two entries for one key, one of which does nothing. It tracks preview
visibility, not focus, so it sits outside this criterion. Worth its own ticket.