fix: explain silent states and ambiguous navigation

[janithcd]

Summary

• show the resolved errors-ai.log path in the tool-window title and empty-log message
• explain when a selected report has no source frame to open
• show a source-file chooser when multiple project files share the reported filename

Why

Several valid states looked like the plugin had silently failed, and jump-to-culprit previously selected the first matching filename even when the project contained duplicates.

Validation

• ./gradlew.bat test
• ./gradlew.bat buildPlugin
• manually verified an empty errors-ai.log
• manually verified a report with no source frame
• manually verified choosing and opening both duplicate OrderService.java files at the reported line

Closes #8

[GabrielBBaldez]

Built and tested it: buildPlugin produces plugin-0.1.0.zip and the :core parser tests are 4/4.

All four silent states from the issue are covered, and you went past what it asked for in the right place. The issue only suggested showing a popup on more than one match; sorting the candidates by path first is the part that matters — files.iterator().next() on an unordered collection could return a different file between sessions, so the same double-click could land somewhere else tomorrow. Sorted, it's at least reproducible, and the popup makes the ambiguity visible instead of silently guessing.

Putting the resolved path in the tool-window title rather than the detail pane is also better than what I had in mind: it's visible without selecting anything, which is exactly when you need it — the monorepo case is about not noticing you're reading the wrong service's log.

One nit I'll fix on merge rather than send you round again: ReportNavigator.java and StacktalePanel.java lost their trailing newline, so git will render \ No newline at end of file in every future diff of those two files.

Merging.

[GabrielBBaldez]

This is your first one here — thanks. If the plugin turns out to be useful to you, a ⭐ on the repo genuinely helps: stacktale is new, and stars are most of what decides whether anyone else finds it.

(There's a workflow meant to say this automatically and it failed twice on the way here — first keying on author_association, which merging a PR changes, then on a 403 because the org forces workflow tokens to read-only. Yours is the PR that debugged the thank-you note.)

The trailing newlines are restored on main. If you want another: #7 is the natural next one and it's the same family of problem you just fixed — the parser drops a report whose block was caught mid-write, and navigates to the wrong file when a frame has a -1 line number (a class compiled without debug info) or a non-ASCII filename. You've now seen how ReportNavigator resolves a frame, which is most of the context that issue needs.