New Fix all in workspace option like dart fix --code= #6144

Is your feature request related to a problem? Please describe.
As discussed on Discord, when enabling several related lints in analysis_options.yaml (e.g. discarded_futures and unawaited_futures, which trigger similar async fixes), there's no good way to preview/apply fixes for just one diagnostic at a time using the "Dart: (Apply/Preview) Fix All in Workspace" command. The preview tree currently groups changes by fix name (the human-readable description), not by diagnostic ID/lint name — but the same diagnostic can have different fixes depending on context (e.g. avoid_local_variable_types can be fixed by removing a type or by replacing it with var), so grouping by fix name doesn't let you isolate "everything related to lint X" the way dart fix on the CLI does (there, you select by --code= with the diagnostic id).

The team's review workflow requires one diagnostic/lint fixed per commit, so today this means enabling lints one at a time in analysis_options, running the preview command, applying, then going back to enable the next one — which is slow when trying to roll out a large batch of lints across a legacy codebase.

Describe the solution you'd like
An option in the "Fix all in Workspace" flow to filter/select by diagnostic name (the id used with dart fix --code=) rather than only by fix description, so multiple lints could be enabled at once but previewed/applied one diagnostic at a time. Ideally, also a way to trigger "Preview Fixes in Workspace" scoped to a single lint directly (e.g. as a code action on the lint name in analysis_options), without needing to enable all the others at the same time.

Describe alternatives you've considered

• Keep enabling and fixing lints one-by-one manually via analysis_options (current workaround, but slow for large batches).
• A command variant that lists all diagnostics in the workspace that have available fixes, letting the user pick one and then showing a filtered fix list for just that diagnostic (suggested by @DanTup as possibly simpler than grouping in the UI).
• Having the analysis server pre-calculate the diagnostic-to-fix grouping when generating the fixes list (mentioned as potentially faster, but not confirmed necessary, and @DanTup noted diagnostic IDs may be non-trivial to surface since the extension uses legacy protocol types internally with limited room for extra data).