feat(intellij): download tombi when unavailable

[ya7010]

Summary

• resolve project-local Tombi installations from .venv, node_modules/.bin, and PATH
• download and cache the latest GitHub release when no local executable is available
• fall back to the newest extension-managed cached binary when a fresh download fails
• keep an explicitly configured executable as the highest-priority choice
• document the automatic setup and cover platform/local-resolution behavior with tests

Validation

• cargo fmt --all --check
• JAVA_HOME=/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home ./gradlew check buildPlugin
• JAVA_HOME=/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home ./gradlew test --tests 'tombi.DiagnosticsTest'
• git diff --check

[github-actions]

Qodana Community for JVM

Analyzed project: editors/intellij/

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked

View the detailed Qodana report

To be able to view the detailed Qodana report, you can either:

• Register at Qodana Cloud and configure the action
• Use GitHub Code Scanning with Qodana
• Host Qodana report at GitHub Pages
• Inspect and use qodana.sarif.json (see the Qodana SARIF format for details)

To get *.log files or any other Qodana artifacts, run the action with upload-result option set to true,
so that the action will upload the files as the job artifacts:

      - name: 'Qodana Scan'
        uses: JetBrains/qodana-action@v2025.2.3
        with:
          upload-result: true

Contact Qodana team

Contact us at qodana-support@jetbrains.com

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions

[InSyncWithFoo]

Two things you might want to note:

• Some people don't like it when things are downloaded fully automatically, as they might have a preferred installation method. Asking for an explicit permission is a much safer bet.
  Personally, I install Tombi using uv and if I didn't have it already I'd prefer to download it myself that way rather than leaving it up to the plugin.
• Bundling the installer logic into the plugin is perhaps not a good choice. Not all users update their plugins, so that means if something were to change upstream, the entire plugin would simply break. What's worse, many would choose disabling plugins for good rather than filing bugs.
  uv's approach is one that I would recommend: Generate installer scripts (I think it uses cargo-dist for this) and serve them over the net, then download and run those using the plugin. It's much more stable this way. See an example implementation here.

[ya7010]

I will revert this PR, review the installation method, and redesign it to ask users for permission to install.

[xtqqczze]

Just noting that the v1.2.5 release notes still list this as a new feature, even though this PR was reverted. It would be good to adjust the release notes workflow so reverted changes aren’t included in future releases.