feat: jump from output file references

[jensenojs]

Summary

This adds a cursor-scoped jump action for file references in the output window.

Pressing <CR> in the output window now jumps from the file reference under the cursor back to the editor area. Existing gf behavior is kept and routed through the same navigation path.

Supported targets include:

• path
• path:line
• path:line:col
• backticked file references
• markdown-style file links
• file:// links
• tool output paths
• diff add/context lines, using the rendered diff gutter line number

Deleted diff lines intentionally do not jump, because they refer to old-file lines.

Design notes

The jump target is resolved at keypress time from the cursor position in the rendered output buffer. The formatter does not register jump actions or decide navigation targets during rendering.

workflow only acts as a command adapter. File opening, target-window selection, line/column clamping, and diff-line handling live in navigation.

Follow-up

This PR only handles file-like output targets.

A follow-up can add symbol-aware output navigation by indexing symbols from files already referenced in the conversation, then using the existing picker layer for multi-target cases.

Tests

• ./run_tests.sh -t tests/unit/config_spec.lua
• ./run_tests.sh -t tests/unit/navigation_spec.lua
• ./run_tests.sh -t tests/replay/renderer_spec.lua
• ./run_tests.sh -t replay

[jensenojs]

One more thing I wanted to mention: @sudo-tee

Since you mentioned you're not using the plugin heavily these days, I'd be happy to step in as a maintainer and help out more actively.

Here's what I had in mind:

• I can maintain a dev branch where I push new features and cleanup work directly, without going through PRs for every change.
• main stays conservative — anything going in there still goes through small PRs, and you have the final say.
• I can also help review PRs targeting main, or jump in on bug fixes.
• For larger changes, I'll open an issue or write up a spec first so everyone can weigh in before code gets written.

The reason I'm asking is that I genuinely want to keep building on this plugin — there are a few features and cleanup ideas I'd like to explore. But I also don't want to add to your maintenance load or push unstable stuff into main.

And hey, if the dev branch ends up being fun enough, maybe it'll even tempt you back into using the plugin more often someday 😄

[sudo-tee]

This looks like a good cleanup.

As for maintenance, I am still active and use the plugin everyday, just a bit less when I'm at work.

But I can give you a maintainer role as you are a good contributor that I trust