Flutter desktop on Linux currently has no equivalent of the --flavor plumbing that already exists for Android, iOS, and macOS: flutter build linux --flavor X is rejected at the command-parser level, flutter run -d linux --flavor X emits a "flavor only supported on Android, iOS, macOS" warning, and there is no convention for producing per-flavor binaries or build directories. This PR wires the existing flavor infrastructure end-to-end on Linux so that multiple flavors can coexist in the same project without colliding on disk or in the runner.

What changes

• flutter build linux accepts --flavor via the shared usesFlavorOption() helper.
• LinuxDevice.supportsFlavors returns true, so flutter run -d linux --flavor X no longer warns and now drives the flavored build pipeline.
• Build directory is namespaced per flavor: build/linux/<arch>/<flavor>/<mode>/ (parity with Android/iOS/macOS). Projects that don't pass --flavor keep the legacy build/linux/<arch>/<mode>/ layout — no migration required.
• CMake configure receives -DFLUTTER_APP_FLAVOR=<flavor> so the generated project can react to the flavor at configure time.
• Generated CMake template suffixes BINARY_NAME with -<flavor> and APPLICATION_ID with .<flavor> when FLUTTER_APP_FLAVOR is defined, matching the Android applicationIdSuffix convention. The branch is guarded by if(DEFINED FLUTTER_APP_FLAVOR AND NOT FLUTTER_APP_FLAVOR STREQUAL ""), so existing projects regenerated from this template behave identically when no flavor is passed.
• Runner template (linux.tmpl/runner/CMakeLists.txt + my_application.cc.tmpl) exposes FLUTTER_APP_FLAVOR as a compile-time preprocessor define (same mechanism already used for APPLICATION_ID) and uses it to suffix the GTK window title, giving projects a one-line entry point for flavor-aware native behavior without any additional Flutter tool surface area.
• Dart-side continues to use the existing appFlavor getter from package:flutter/services.dart, which reads FLUTTER_APP_FLAVOR from the dart-defines that toEnvironmentConfig() already produces. No framework changes required.

Design choices

• APPLICATION_ID suffix mirrors Android (it.example.app → it.example.app.free) so packaging tooling and .desktop files have a stable convention to key off.
• Per-flavor build directory matches the layout the other platforms already use, so users can ls build/linux/x64/ and see each flavor side-by-side.
• Flavor-specific assets, icons, .desktop files, and snap/deb packaging remain the project's responsibility — this PR intentionally keeps the tool agnostic and only standardizes the plumbing.

Tests

• New test/general.shard/linux/build_linux_flavor_test.dart covers:
  • flutter build linux --flavor apple invokes CMake with -DFLUTTER_APP_FLAVOR=apple and a flavored working directory, and the success log references build/linux/x64/apple/release/bundle.
  • getCmakeExecutableName returns the base binary name without a flavor, and name-flavor when a flavor is provided (empty string treated as no flavor).
• Existing test/commands.shard/hermetic/build_linux_test.dart (25 cases) continues to pass with no changes, confirming the legacy no-flavor path is unaffected.

Manual verification

Generated an example project, then ran the full matrix:

flutter build linux --flavor apple   # → build/linux/x64/apple/release/bundle/example-apple
flutter build linux --flavor banana  # → build/linux/x64/banana/release/bundle/example-banana
flutter build linux                  # → build/linux/x64/release/bundle/example (unchanged)
flutter run -d linux --flavor apple  # launches, no "unsupported flavor" warning

All three builds coexist in build/linux/x64/ without overwriting each other, and the Dart UI reads appFlavor correctly at runtime in each binary.

Backward compatibility

• Projects that never pass --flavor see no change: same build directory, same binary name, same APPLICATION_ID, same generated CMake.
• Existing projects do not need to regenerate linux/CMakeLists.txt to keep working; they only need to regenerate (or hand-patch the if(DEFINED FLUTTER_APP_FLAVOR) branch) to opt into flavor support.

Fixes #162373

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.