Offer the rendered diff in the editor context menu for committed diffs

[wolframarnold]

Fixes #61. Follow-up to #60.

After #60, the title-bar button renders a committed revision diff, but right-clicking inside that diff editor still does not offer Show Rich Markdown Diff. The button's when uses the built-in isInDiffEditor context; the editor context menu is gated on rich-markdown-diff.canShowRenderedDiff. The two disagreed.

Why the context key stayed off

updateRenderedDiffContext computes the key. When a committed diff is focused, the active editor is the modified side — a git: URI carrying the commit ref. Lines 557–562 rebuild it as a plain file: URI, dropping the ref (the same root cause as #59). The comparison then resolves as HEAD-vs-working-tree; a committed blob isn't dirty; isActionableSingleFileComparison returns false → key stays off → menu item hidden.

What changed

• getActiveRevisionComparison (commandTarget.ts) reuses Render diffs for committed changes, not just uncommitted ones #60's getActiveDiffTabUriPair and getRevisionComparison to report the revision diff the active tab is showing.
• updateRenderedDiffContext short-circuits to canShow = true when the active tab is a markdown revision diff, before the ref-dropping fallback runs. The isMarkdownPath(toFileBackedUri(...)) check keeps a non-markdown revision diff in another editor group from enabling the key (reachable via the existing updateRenderedDiffContext(mdEditor) recursion, where the passed editor and the active tab can differ).
• setCanShowRenderedDiff factors out the "set the key only if the value changed and this update hasn't been superseded by a newer generation" logic that was duplicated at two call sites, and is used at the new site too.

No package.json when clauses change: the menu already requires (editorLangId == markdown || resourceLangId == markdown) && rich-markdown-diff.canShowRenderedDiff. Only the context key's value is corrected.

Scope is deliberately narrow — the key flips to true only for a markdown diff whose active tab names a commit, tag, or branch ref. HEAD-vs-working-tree and staged diffs still resolve through the unchanged path (getRevisionComparison returns undefined for HEAD, "", and ~), so no existing behavior moves.

Tests

3 new integration tests in commandTarget.test.ts (50 → written before the code): a commit-to-commit diff tab is detected, while a HEAD-to-working-tree tab and a plain markdown editor are not. test:unit stays at 150. pnpm run pretest is clean.

The context-key side effect isn't observable through the public API, so — as in #60 — I proved the wiring end-to-end with a temporary harness against a real two-commit git repository: opening the committed diff and driving the context update flipped the module's lastCanShowRenderedDiff to true. With only the new short-circuit disabled (helper and tests left in place), the same harness reported false, reproducing #61 exactly. The harness is not included in the PR.

Note

Verified programmatically that the context key now flips to true for a committed markdown diff (above). The menu's when clause is that key plus the markdown language gate, both satisfied, so the right-click item should now appear; a maintainer running a build can confirm the live menu.

[wolframarnold]

Verified live in VS Code 1.130.0 (Windows) with a local build of this branch: on a committed .md diff opened from the built-in Source Control Graph, right-clicking inside the diff editor now shows Select for Markdown Diff / Show Markdown Diff, and the rendered diff opens correctly. The title-bar button (from #60) continues to work on the same committed diffs.

For reference, one thing that is intentionally not addressed here: the inline hover icon on a file row still can't appear under a commit in the Graph. VS Code exposes no per-change menu hook there — the finest history/graph contribution point is scm/historyItem/context (whole commit), with no equivalent of scm/resourceState/context's inline group for a commit's individual files. So that would need an upstream VS Code API before it's possible in the extension.