feat: add Linux desktop support to core, auth, firestore, database, storage, remote_config, app_check

[akshaynexus]

Description

Adds Linux desktop support to seven FlutterFire plugins, mirroring the existing Windows desktop implementation (same Firebase C++ SDK 13.5.0, same development-only support policy):

firebase_core, firebase_auth, cloud_firestore, firebase_database, firebase_storage, firebase_remote_config, firebase_app_check

These are exactly the products the Firebase C++ SDK provides real (non-stub) desktop implementations for.

What was added

• linux/ implementation per plugin targeting Flutter's GLib/GObject Linux embedder (FlPluginRegistrar, FlValue, FlMethodChannel, FlEventChannel) — ported from the windows/ C++ implementations. 123 Pigeon host-API methods and 14 event channels (auth state / ID token, Firestore document & query snapshots + snapshots-in-sync, Database value/child listeners, Storage task progress, Remote Config update listener, App Check token changes).
• Pigeon codegen, not hand-written channels: each *_platform_interface/pigeons/messages.dart gained gobjectHeaderOut/gobjectSourceOut outputs, so the Linux channel layer is generated from the same single source of truth as every other platform. A melos generate:pigeon:linux script (scripts/generate_pigeon_linux.sh) re-applies the small mechanical post-gen transforms the GObject generator needs (reserved-word delete → delete_ for auth, dispatch-local handle rename for storage, Firestore custom-codec delegation) so a raw dart run pigeon can't silently regress them.
• CMake / SDK download modeled on the Windows CMakeLists: same FIREBASE_SDK_VERSION (13.5.0), same FIREBASE_CPP_SDK_DIR env override with version check. Linux downloads the full firebase_cpp_sdk_13.5.0.zip (Google publishes no Linux-only archive); the SDK's own CMake selects the correct x86_64 C++11-ABI static libraries.
• Link architecture (the part that differs from Windows by necessity): the prebuilt Firebase static archives have circular symbol dependencies (product libs → firebase::rest::* inside libfirebase_app.a; libfirebase_firestore.a → firebase::g_auth_initializer inside libfirebase_auth.a). GNU ld resolves archives left-to-right (unlike MSVC), so firebase_core_plugin owns the SDK link and wraps all product archives in a single -Wl,--start-group/--end-group, plus libsecret-1 (forwarded from the SDK's own firebase_auth interface requirement), system OpenSSL (needed by Database/Firestore archives), and pthread. Product plugins link only firebase_core_plugin. Plugins are built as STATIC libraries (as on Windows) so all plugins share one firebase::App registry in the runner.
• Cross-plugin constants registry: FlValue-based FlutterFirebasePluginRegistry in firebase_core, mirroring the Windows/Android registry, so initializeCore aggregates each plugin's constants.
• Repo integration: Linux column in the root README support matrix (marked development-only, same (*) policy as Windows), linux/ runners for each plugin example and for the tests/ app, and a build-only Linux CI workflow (.github/workflows/linux.yaml, ubuntu-latest) that builds the firebase_core example.
• Where the Windows implementation has TODO stubs for APIs the C++ SDK does support, the Linux port implements them (e.g. FirebaseAppHostApi.delete destroys the firebase::App instance); where the SDK genuinely lacks the API, the Windows no-op is mirrored with the same comment.

What was tested (real hardware)

All builds were verified on physical Linux hardware (CachyOS, Flutter 3.44.4 stable, CMake 4.4, GCC/Clang toolchain), not just cross-checked statically:

• flutter build linux succeeds for all seven plugin example apps, including the full SDK zip download/extract path in firebase_core's CMake and the FIREBASE_CPP_SDK_DIR override path for the rest.
• flutter build linux succeeds for the tests/ app, which links six FlutterFire plugins into one binary (core, auth, app_check, database, remote_config, storage) — verifying the plugins coexist and the group-link strategy holds under multi-plugin aggregation.
• Symbol-level verification with nm on the produced binaries: every <plugin>_plugin_register_with_registrar entry point present, product SDK symbols linked (e.g. 1,166 firebase::auth::* symbols in the auth example binary).
• Launch smoke test: binaries start and reach GTK initialization (headless SSH session, so no display was attached).
• flutter analyze clean on the touched Dart surfaces.

What works / known limitations

• Works: app initialization & multi-app, Auth flows over the C++ desktop SDK, Firestore (queries, snapshots listeners, transactions, custom codec for Firestore types), Realtime Database (listeners, transactions), Storage (upload/download tasks with progress events), Remote Config, App Check host APIs.
• Development-only, exactly like Windows: the Firebase C++ desktop SDK is a beta/dev workflow, so the README marks Linux with the same (*) footnote.
• Limitations deliberately mirrored from Windows for parity: Remote Config realtime-update callbacks never fire (desktop SDK limitation), setCustomSignals responds unimplemented, Database setPersistenceCacheSizeBytes/emulator wiring no-ops, Firestore VectorValue wire type not decoded natively, Auth MFA/TOTP host APIs generated but not registered (Dart receives channel-not-implemented, as on Windows).
• E2E test wiring for a Linux runner (emulator jobs mirroring windows.yaml) is left as follow-up; the added CI job is build-only.
• The auth example's font_awesome_flutter/flutter_signin_button pair is bumped to the latest versions (fa 10 does not compile on Flutter ≥ 3.44 where IconData is final). No released flutter_signin_button supports fa 11 yet, so the workspace root carries a temporary dependency_overrides onto a patched fork; fix: support font_awesome_flutter 11 (FaIconData is no longer an IconData) ZaynJarvis/Flutter-Sign-in-Button#125 has been opened upstream to make that override removable. If maintainers prefer, this dep bump can be split into a separate PR.

Related Issues

• 🐛 [firebase_auth] Linux support request 🚀 #17338 (Linux support request for firebase_auth) — this PR provides it, along with six more plugins.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide). — Native Linux behavior is verified by building and symbol-checking all seven examples plus the multi-plugin tests/ app on real Linux hardware; no Dart behavior changed (the Dart/Pigeon layer is shared with existing platforms and covered by existing tests). Happy to add Linux e2e wiring in a follow-up.
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (melos run analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change.
• No, this is not a breaking change.

🤖 Generated with Claude Code

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

[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.