Inline git blame on the cursor line in the editor

What problem does this solve?

I am trying to go all-in on Terax and stop keeping a separate code editor open alongside it. Two things still pull me back to the other editor during normal work: checking who last changed a line, and seeing at a glance what has changed since the last commit.

The second one is being handled separately (#1282, source control decorations that follow file changes). This issue is about the first. Right now answering "who wrote this line, when, and why" means leaving the file: open the git history pane, find the commit, find the file, find the hunk — or give up and switch to the other editor, which is what actually happens. The metadata is one git blame away.

I am aware this is the kind of request that turns a terminal into an IDE if it is granted without limits, which is why the proposal below is deliberately the smallest version: cursor line only, opt-in, no gutter column, nothing running when it is off.

Proposed solution

Annotate the line under the cursor with the last commit that touched it — author, relative age, commit subject — rendered dim at the end of the line, the way GitLens does it. Nothing on other lines, nothing in the gutter.

Behavior:

• Off by default, behind an editorInlineBlame setting in Settings > Editor. With it off, no extension is installed and the feature costs nothing.
• Only the visible tab is blamed. Editors stay mounted behind the active tab, so background files must not spawn git processes.
• Annotations are line-indexed against the file on disk, so they clear on the first local edit and come back on save. They stay off entirely while the buffer is dirty.
• Refetch is event-driven: on save, and on the fs:changed event the editor already watches, so a pull or checkout updates it. No polling, no watcher of its own.
• Backend is one git_blame command returning per-line metadata only (no file content), bounded with -L and capped at 20,000 lines, gated through the workspace authorization registry like the other git commands.

Open questions I would rather settle before more code:

1. Is inline blame a direction you want in the editor at all, or does it read as IDE creep? The roadmap keeps focused editor workflows in scope when they are opt-in, lazy and resource-bounded, which is what I aimed for, but the call is yours.
2. Cursor-line only, or also a "blame the whole file" view later? I would rather ship only the first.
3. Should the annotation be clickable (open the commit in the history pane)? Not implemented; it is currently pointer-events: none.

Alternatives considered

• Using the existing git history pane — works, but it is a context switch per question.
• A gutter column of authors — more information per screen, but it is permanent visual noise and costs a decoration per visible line.
• Doing nothing and living with git blame in a terminal split. Honestly a reasonable answer if the feature does not fit the product.

Are you willing to contribute the implementation?

Yes, I can do it — an implementation already exists in #1279, opened before this discussion. Happy to have it closed if the answer here is no; the PR is the proposal, not a fait accompli.

Before submitting

• I searched existing issues and didn't find a duplicate