feat(walkthrough): guided AI walkthrough for diffs, branches, and PRs (#2572)

A diff is ordered by file path, which is almost never the order in which a
change makes sense. This adds a Walkthrough surface that reorders it: the model
groups related hunks into stops, explains what each group changes about
behavior, and orders the stops so each builds on the last. It explains and
orders; judging code stays with the existing Review action.

Reviews uncommitted work (all, staged, unstaged), a branch against its base, or
a pull request. Generation is always user-initiated — nothing runs on a timer,
on a file change, or as a side effect of opening a panel.

Invariants worth preserving:

- Hunk identity is derived on the server and only there. Ids are content
  hashes, so an anchor that no longer resolves is proof the code it described
  changed, and staleness needs no heuristics. The client matches ids to ids and
  never recomputes them; two implementations would have to agree forever.
- The digest is never truncated. A diff that does not fit the model's context
  is refused with an actionable reason, because a walkthrough written against
  half a diff reads as confident and is wrong.
- Nothing disappears. Lockfiles and other generated output are excluded from
  the model's input by name — never by size — and everything no stop covers is
  listed at the end, so "have I seen all of it" stays answerable.
- Cost is explicit. Results are content-addressed, so returning the working
  tree to an earlier state costs nothing; generation outlives its request, so a
  refresh detaches the client rather than discarding paid-for work, and only an
  explicit cancel stops it.

Supporting changes to shared modules:

- git: expose the existing getRangeDiff as GET /api/git
  listUntrackedPaths and getUntrackedDiffs. The latter resolve the repository
  once for a batch instead of per file, taking a panel
  ~340ms on an 80-file working tree.
- small-model: structured output across four wire forma
  and abort signal, and an onOverflow policy so an oversized prompt fails
  loudly instead of being silently clipped. A provider
  remembered so the prompt-side fallback goes first next time.
- models.dev metadata: surface structured_output as tri
  false blocks a model, a missing field does not, because the catalog omits it
  for roughly half of all models.

Desktop and tablet only: VS Code serves Git through its
these routes, and the mobile shell does not consume the surface registry.

Docs: packages/docs walkthrough page in English and all eight locales.

packages/docs/content/docs/walkthrough.mdx

@@ -0,0 +1,63 @@
+---
+title: Changes Walkthrough
+description: Read a diff in the order it makes sense, not in alphabetical order.
+---
+
+# Changes Walkthrough
+
+A diff is sorted by file path, which is almost never the order in which the change makes sense. The walkthrough reorders it: related edits are grouped into **stops**, each stop explains what the code now does differently, and the stops are ordered so each one builds on the last.
+
+It explains and orders. It does not judge your code or hand out verdicts — that is what [Review](/git/) is for.
+
+Open it from the **Walkthrough** icon in the right rail, or from the **AI walkthrough** button in the Changes and Pull Request panels. Both just open the panel; nothing is generated until you press **Generate walkthrough**.
+
+## What it can review
+
+| Scope | What it covers |
+| --- | --- |
+| All uncommitted | Everything not yet committed: staged, unstaged, and new files |
+| Staged | Only what would go into a commit right now |
+| Unstaged | Working tree and new files |
+| This branch | Every commit on this branch that is not on its base |
+| Pull request | The change as it exists on GitHub |
+
+**This branch** is not "unpushed commits" — it is everything the branch adds to its base, pushed or not. So after committing but before pushing, it and the pull request deliberately differ: one shows what you did, the other what reviewers currently see.
+
+Each scope is stored separately, so switching between them never loses anything.
+
+## Choosing the model
+
+Walkthroughs use your small model by default. Pick a different one in **Settings → Sessions → Changes Walkthrough Model**, or for a single review in the panel header — useful when a change is risky enough to deserve a stronger model.
+
+The picker only offers models that can return structured output, because the walkthrough cannot be assembled without it. If a model is too small for the diff, generation is refused with an explanation rather than silently truncating the input: a walkthrough written against half a diff reads as confident and is wrong.
+
+Reopening a panel shows the model that produced what you are looking at, so **Regenerate** repeats with the same one unless you change it.
+
+## Cost and caching
+
+Nothing generates on its own. Generation only ever starts when you ask, and regeneration is manual too.
+
+Results are cached against the exact content of the diff. Return the working tree to an earlier state and the earlier walkthrough comes back for free, no model call. Switch models and back, and each one's walkthrough is still there.
+
+Generation runs on the OpenChamber server, not in your browser tab. Reload the page or close the panel and it keeps going; come back and the result is waiting. Pressing **Cancel** is the only thing that stops it.
+
+## Staying honest about staleness
+
+Every stop is anchored to the exact content of the code it describes, so the panel can tell you when that code has moved on:
+
+- **Outdated steps** — the code a stop described has changed or is gone. The walkthrough still shows, marked, so you can decide whether to regenerate.
+- **Not covered** — changes in the current diff that no stop describes. That includes edits made after generating, changes the walkthrough judged routine, and lockfiles and other generated files, which are deliberately kept out of the model's input. They are all listed at the end of the stream so nothing disappears silently.
+
+Regenerating re-authors rather than patches: the previous walkthrough goes to the model as context so accurate parts survive, and everything is re-anchored to the current code.
+
+## Notes
+
+- Comment on any line in the walkthrough exactly as in the diff view; comments attach to the chat composer.
+- Available on desktop and tablet widths. Not offered in the VS Code extension or the mobile app.
+- A pull request review needs a connected GitHub account — see [GitHub Issues & PRs](/github/).
+
+## Related
+
+- [Git & GitHub](/git/) — the Changes panel this reads from, and the Review action that does judge code
+- [GitHub Issues & PRs](/github/) — connect GitHub to review pull requests
+- [Providers, Models & Agents](/providers/) — where the small model comes from