[stable] [flutter_tools] Validate plugin class/package identifiers to prevent GeneratedPluginRegistrant injection - #191294

…GeneratedPluginRegistrant injection (flutter#189156)

## Description

Plugin `pluginClass`/`dartPluginClass` and the Android `package` are
interpolated **verbatim** into the generated `GeneratedPluginRegistrant`
source files. `flutter_plugins.dart` renders these templates via
`_renderTemplateToFile` → `templateRenderer.renderString(template,
context)`, and the renderer's `htmlEscapeValues` defaults to `false`, so
the values are emitted with no escaping into Java/Kotlin, Swift,
Objective-C and C++ source (e.g. `new {{package}}.{{class}}()`,
`{{prefix}}{{class}}.register(...)`, `#import <{{name}}/{{class}}.h>`).

The per-platform `validate()` methods in `platform_plugins.dart` only
checked that these fields were *strings*, not that they were valid
identifiers. As a result a plugin declaration whose
`pluginClass`/`package` contains arbitrary source (spaces, `;`, `{}`,
`()`, newlines, …) passes validation and that source lands in the
consuming app's `GeneratedPluginRegistrant` and is compiled into the
app.

Because plugins are collected over `computeTransitiveDependencies(...)`
with no opt-in from the consuming app, a **transitive** dependency can
use this to have arbitrary native code compiled into an app that merely
depends on it (via a plain `flutter pub get` / `build` / `run`). This is
the same "a package must not escape its declared boundary at build time"
boundary enforced for asset paths in flutter#187661 and for pub-cache
extraction in CVE-2026-27704.

Reproduced end-to-end: a dependency declaring
```yaml
flutter:
  plugin:
    platforms:
      macos:
        pluginClass: "SomePlugin.register(...); <injected statements>; if false { SomePlugin"
```
resulted, after `flutter pub get`, in the injected statements appearing
verbatim in `macos/Flutter/GeneratedPluginRegistrant.swift` and
`ios/Runner/GeneratedPluginRegistrant.m`.

## Fix

Restrict `pluginClass`, `dartPluginClass` and the Android `package` to
identifier characters (dot-separated identifiers) in each platform's
`validate()`, rejecting the plugin specification otherwise. Legitimate
class/package names are unaffected; a value that is not a plain
identifier now fails with `Invalid plugin specification <name>`.

## Tests

- Added a regression test asserting a `pluginClass` containing injection
characters is rejected.
- Full `test/general.shard/plugins_test.dart` passes (77/77) — no
legitimate plugin specification regresses.

## Pre-launch Checklist

- [x] I added new tests to check the change I am making.
- [x] All existing and new tests are passing.

---------

Co-authored-by: Ben Konyi <bkonyi@google.com>