Warn before Flutter upgrade on Windows

[LyViolz]

Addresses #7668.

On Windows, running flutter upgrade from inside the IDE can fail because Dart SDK files may still be locked by IDE processes.

This change prevents the upgrade action from starting on Windows and instead shows a message instructing users to close the IDE and run flutter upgrade from a terminal.

Linux and macOS behavior is unchanged.

Testing

• ./gradlew compileJava
• ./gradlew test --tests 'io.flutter.actions.*'

Both completed successfully.

The Windows-specific runtime behavior was not tested locally.

[gemini-code-assist]

Code Review

This pull request adds a warning dialog for Windows users when attempting to upgrade Flutter from within the IDE, as the Dart SDK may be locked by active IDE processes. The review feedback highlights two issues: first, the overridden actionPerformed method in FlutterUpgradeAction needs to report analytics before returning early on Windows to comply with the repository style guide; second, the double single quotes in the newly added properties message should be replaced with single quotes, as the message does not contain format parameters and would otherwise render literally.

[gemini-code-assist]

[CONCERN] In IntelliJ properties files, single quotes should only be doubled (''...) if the message contains format parameters (like {0}). Since this message does not contain any parameters, the double single quotes will be rendered literally as double single quotes in the UI. Use single quotes instead.

flutter.upgrade.windows.message=Flutter upgrades can fail on Windows while the IDE is running because the Dart SDK may be locked by IDE processes. Close the IDE and run 'flutter upgrade' from a terminal instead.

[helin24]

Does this upgrade command always fail on windows? (I am trying to understand if this change is likely to raise complaints from others who are using the upgrade successfully)

The associated issue also mentions that other SDK commands also fail. Are you able to reproduce that as well? If so, we may want this suggestion within the superclass instead of overriding just for upgrade.

[LyViolz]

Thanks for the clarification.

I haven't been able to reproduce the Windows-specific failure locally, since my development environment is Linux, so I can't confirm that flutter upgrade always fails on Windows or that the other SDK commands mentioned in the issue fail under the same conditions.

My change was based on the issue reports describing Dart SDK files being locked while the IDE is running. Given your concern, I agree that blocking flutter upgrade unconditionally on Windows may be too broad if the command works successfully for some users.

I can revise the approach once we determine whether this is specific to upgrade or applies to SDK commands more generally. If the same locking condition affects multiple commands, handling it in the superclass sounds more appropriate.