Keep Flutter SDK cache entries distinct for symlinked paths

[fernando-s97]

Summary

Prevent FlutterSdk cache entries from collapsing distinct configured SDK paths that resolve to the same canonical target. This preserves each project's selected path, including project-local FVM symlinks, when resolving its SDK instance.

This addresses the cache-identity aspect of #6616. It does not change IntelliJ's SDK-directory chooser behavior.

Verification

Manual verification still needed:

1. Configure projects with distinct SDK symlink paths that resolve to the same Flutter SDK.
2. Verify each project retains and resolves its configured SDK path independently.

Automated verification:

• git diff --check passed.
• OpenJDK 21 installed locally.
• ./gradlew --no-configuration-cache --no-daemon --console=plain -Dkotlin.compiler.execution.strategy=in-process test reached successful Java compilation (one pre-existing deprecated API warning), but did not reach test execution: Gradle remained waiting on an included build after compilation and produced no test-result XML. This draft remains pending a completed test run.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.
• I've included the required information in the description above.
• My up-to-date information is in the AUTHORS file.
• I've updated CHANGELOG.md if appropriate. This bug fix does not add a user-facing release-note entry.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request modifies the Flutter SDK caching mechanism to use the normal path instead of the canonical path, preventing SDK leaks across projects using symlinks (e.g., FVM). It also replaces the IntelliJ FileChooser with Swing's JFileChooser in the settings configuration. The review feedback highlights that using JFileChooser on the Event Dispatch Thread (EDT) introduces severe threading violations (potential UI freezes) and a UX regression, and recommends reverting to the standard IntelliJ FileChooser.

[gemini-code-assist]

[MUST-FIX] Reverting to Swing's JFileChooser introduces a severe threading violation and a major UX regression.

1. Threading Violation (EDT Freeze): JFileChooser performs synchronous disk I/O (scanning directories, loading system icons, resolving network shares) on the Event Dispatch Thread (EDT) during initialization and when showOpenDialog is called. This can cause the entire IDE UI to freeze/hang, triggering "Application Hanging" reports and a poor user experience.
2. UX Regression: JFileChooser uses the generic Swing look-and-feel, which does not match the IntelliJ theme, lacks IDE-specific features (like favorite paths, recent paths, virtual filesystems), and does not support remote development environments (e.g., JetBrains Gateway).

Please revert to the standard IntelliJ FileChooser. If preserving symlinks is a priority, we should explore alternative ways to handle this without resorting to JFileChooser on the EDT, or let users manually type/paste the symlink path in the editable combo box.

Note: Please also restore the deleted imports (FileChooser, FileChooserDescriptor, FileChooserDescriptorFactory, VirtualFile) and remove the unused java.io.File import.

          FileChooserDescriptor descriptor = FileChooserDescriptorFactory.createSingleFolderDescriptor();
          VirtualFile file = FileChooser.chooseFile(descriptor, mySdkCombo, null, null);
          if (file != null) {

References

1. NEVER perform heavy operations (I/O, complex PSI searches) on the Event Dispatch Thread (EDT). ^(link)