[core] Decouple platform_interface from Flutter for pure-Dart web

[kevmoo]

Context & Problem

Recent cleanups (#18604, #18624) removed package:flutter/foundation.dart, package:flutter/material.dart, and package:flutter_web_plugins imports from *_platform_interface data models and firebase_core_web. Because FlutterFire web implementations (firebase_core_web, firebase_auth_web, cloud_firestore_web) are built on dart:js_interop and package:web, they can compile to JS and Wasm GC without pulling in dart:ui or the Flutter engine.

However, non-Flutter Dart web frameworks (e.g. Jaspr) and pure-Dart environments cannot resolve these packages using standalone dart pub get because firebase_core_platform_interface (and sibling *_platform_interface packages) still declare flutter: sdk: flutter in pubspec.yaml.

The sole remaining reason *_platform_interface depends on flutter: sdk: flutter is that it bundles the default MethodChannel* implementation (package:flutter/services.dart). Meanwhile, package:plugin_platform_interface itself is already 100% pure Dart.

Proposed Options

We would like feedback from the maintainers on two architectural options to remove the flutter: sdk: flutter dependency from the platform interface layer:

Option A: Move MethodChannel* out of *_platform_interface (In-Place Pure Dart)

• Move MethodChannelFirebase (package:flutter/services.dart) from firebase_core_platform_interface into the app-facing firebase_core package (or a dedicated firebase_core_method_channel subpackage).
• Remove flutter: sdk: flutter and environment: flutter: from firebase_core_platform_interface/pubspec.yaml.
• Pros: Zero new packages; *_platform_interface becomes 100% pure Dart immediately.
• Cons: Technically a breaking change for external consumers or test suites that directly instantiate MethodChannelFirebase from firebase_core_platform_interface (requires scheduling for the next major version bump).

Option B: Extract Pure-Dart Leaf Package (package:firebase_common / *_interface)

• Extract pure-Dart platform contracts and shared domain models (FirebaseAppPlatform, FirebaseOptions, FirebaseException, Timestamp, GeoPoint, etc.) into a zero-dependency pure-Dart package (e.g. package:firebase_common).
• Have *_platform_interface re-export these types alongside MethodChannel*, while *_web packages depend directly on the pure-Dart package.
• Pros: 100% backwards-compatible; requires no major version bump to existing *_platform_interface packages; enables code sharing with server-side firebase-admin-dart.
• Cons: Introduces a new leaf package to publish and maintain in the monorepo.

Acceptance Criteria

• Select preferred direction (Option A vs. Option B) for decoupling MethodChannel* (package:flutter/services.dart) from the pure-Dart interface layer.
• Confirm whether pure-Dart platform interfaces should standardize exclusively on FirebaseException rather than catching/throwing PlatformException.

[kevmoo]

CC @schultek

[russellwheatley]

Hey @kevmoo, @Lyokone isn't back for another week but I'll add my two cents.

Option B would be my choice. With option A - there's a slightly bigger degree of risk given we have to update how the MethodChannel default gets installed, and it requires a breaking change.

I think public API stays FirebaseException, PlatformException stays MethodChannel-only.