v0.5.1

Changed

• Four oversized files split into modules. No behaviour change — every
  function kept its name, its signature, and the comment explaining it. This is
  purely about being able to find things: App.tsx was 2034 lines and eighteen
  components, so reaching ApplyPanel meant scrolling past nine others, and
  extension.ts was 1897 lines of which ~1500 were one class, so adding a stack
  operation meant landing in the middle of it.

  • src/webview/App.tsx → 62 lines, now only the loading and error gates.
    The eighteen components moved to components/, the two full-screen views to
    views/, the useState block and its message listener to
    hooks/useHostState.ts, and the pure helpers to lib/.
  • src/extension.ts → 36 lines, now activate/deactivate and the
    command registrations. StackViewProvider moved to src/view/provider.ts
    and the nine stack operations to src/view/operations/, alongside the
    confirmation modals, the QuickPick builders, and the git helpers.
  • src/webview/styles.css → an index of nine @imports. Cut on line
    boundaries rather than by concern: the source interleaves them, and
    .badge--new, .badge--pr-base, and .trunk--current all depend on where
    they sit in the cascade rather than on what they are named. esbuild inlines
    the imports, so the emitted dist/webview.css is byte-identical.
  • test/apply.test.ts → four suites (apply, session, preflight, sync-base)
    over a shared test/support/repo.ts. Every test name is verbatim, so a
    failure report still points at the same thing. 154 tests before and after.

  The operations reach back into the provider through one narrow Host
  interface rather than six arguments each, and the lastX fields stay private
  behind getters — several operations deliberately re-read them after an
  await refresh(), so they have to be live reads and not values captured at
  call time. The "an apply is in progress" warning, previously copy-pasted eight
  times, collapsed to one blockedByApply helper; both of its wordings survive,
  since the one shown next to the plan panel points at buttons the other cannot
  assume are on screen.

  The bare execFile git helper moved as-is and was deliberately not switched
  to git.ts's logged run() — that would put every checkout in the output
  channel and change the child environment, which is a behaviour change and not
  this one.

Fixed

• Rolling back reported a failure for a rollback that worked. The plan panel
  renders Roll back from phase: 'failed' plus canUndo, and the rollback
  emitted exactly that pair on its way out — so the button came back for a
  session it had just cleared, and pressing it a second time answered
  Restack: No apply in progress. Nothing had gone wrong; the panel was
  offering to undo an undo, and the honest answer to that read as an error. The
  final state now says canUndo: false, so a finished rollback offers Show log
  and Dismiss and nothing else.

• The rows kept showing the order the apply produced, after undoing it.
  Rolling back puts the branches and .git/gh-stack back exactly as they were
  — that part was always covered by tests — but nothing re-read them
  afterwards. Every other operation that moves refs refreshes; abort was the one
  that did not, so the repository was restored while the panel still rendered
  the change that had just been taken back, with no way to tell the undo had
  landed short of reloading the window. Abort now refreshes like the rest.

  The restore itself is covered by tests; whether the view then re-reads it is
  the provider's, which has no automated coverage — so that half was verified by
  hand against sandbox/.