Add forge-neutral commit-by-commit and version comparison walkthroughs

[xortive]

Background

I like to author MRs/PRs with structured commits that are meant to assist the reviewer in understanding the change, by breaking out refactors or code movement into early commits, and leaving the actual semantic intent of the change for later commits. Combined with stacked diffs, this is my preferred way to submit changes.

However, the native review process for these in the popular git forges is often pretty bad. Some forges like gitlab, implement "version comparison" where a new push or update to the MR's destination generates a new "version", such that you can review the diff between "versions" of your MR. For forges that don't implement this, I would often settle for uploading !fixup commits as a workaround, and squashing them before merge.

This MR introduces many new features intended to make MRs of this nature easier to review.

New features

There's quite a bit of new functionality in this PR intended to improve the experience of using codiff to review MRs in this form:

• The non-walkthrough "tree" diff viewer, can now review commit(s) in addition to reviewing the entire MR.
  • I suspect this should be a "commit range" and not a list where arbitrary commits can be selected, and need to address that
• The non-walkthrough "tree" diff viewer, can use version information provided by a git forge, to perform a version comparison. A version comparison is the diff of diffs, i.e. diff(diff(vFrom_start,vFrom_end), diff(vTo_start, vTo_end)).
  • Version comparisons notably do NOT include the diff introduced by a rebase. Any changes to the MR itself to accommodate for conflicts introduced by a rebase will still be shown.
• Walkthroughs can now be generated commit-by-commit, with separate independent agent generations, run in parallel, for each commit in a MR. A heuristic detects when a MR should be reviewed as a whole, vs commit-by-commit, by looking for target phrases and certain attributes of an MR.
• Walkthroughs can also be generated when doing a version comparison. Commits of the "to" diff in a version comparison are classified in relation to the "from" diff -- did they change an existing commit? is the commit new? did the commit get moved into the MR base during a rebase? was a commit deleted?
  • All of this context is fed into the walkthrough agent for each commit section in the "to" diff, allowing walkthroughs to guide you through the changes made since your last review.
• There's some work here to consolidate the UI in codiff with our internal codiff-web deployment.

TODO

So far, I believe I've gotten all of the local equivalents to codiff-web features working against gitlab, and some of the features work using the github provider. There's a few things still missing:

• version comparisons derived from github force push information
  • I'm unsure if these will be practical -- if old MR heads are not available, it might not be possible to determine the "from" diff in a version comparison. EDIT: I think this is doable... github caches the old MR heads for some time, and we only care about that if they aren't present in the local repo.
• testing if the web/ share UI supports the new walkthrough variants
• local skill generated walkthroughs from inside an agent harness do not support the new walkthrough variants. I think this is fine, considering the typical usecase for these.
• add evals for new walkthrough variants

[cpojer]

This PR is not merge-able as is. Please run vpr test:all and fix all the issues. It completely breaks the layout of the app:

There is also a slop list of more issues:

2. P1 — Commenting on shared working-tree walkthroughs regresses.

   core/SharedWalkthroughApp.tsx:2997 derives commenting capability from source.type ===
   'pull-request'. A signed-in working-tree share can provide onSubmitComment while not being
   a pull request, but core/app/components/ReviewCodeView.tsx:1561 hides submission anyway.

   This should remain capability-based—such as canSubmitReviewComments—rather than source-
   type-based.

3. P2 — GitLab comment-position comparison can reject a valid fetched comment.

   gitlab/src/history.ts:1007 correctly fetches discussions when a comment-position endpoint
   is requested, but gitlab/src/history.ts:1027 discards those anchors whenever the caller
   supplied any nonempty comment array.

   I reproduced this through the built package: GitLab returned gitlab:42, but supplying an
   unrelated gitlab:7 caused:

   Unknown comment position for version comparison: gitlab:42

   Merge or search both anchor collections instead.

4. P3 — Unrelated workspace configuration disables VS Code Git.

   .vscode/settings.json:33 adds "git.enabled": false. That disables Git integration for
   everyone using the workspace and appears unrelated to “Build Core when installed from
   Git.”

[xortive]

fixed vpr test:all and pushed up the remaining commits to get the local app working again, and added a real, old school, MR description :) I'll add some screenshots tomorrow