Forward a compile-time agent id to native for test tooling

[ctufts]

What does this pull request do?

Adds test-only plumbing that forwards a compile-time identifier to the native side of this plugin, for use by our internal test tooling.

• Reads an optional identifier via --dart-define=MAPBOX_AGENT=<id> (compiled into the Dart binary; empty by default).
• When set, forwards it to native as early as possible (before the platform view / native map engine is created), over the same per-map MethodChannel this plugin already uses for other startup configuration (platform#setMapboxAgentId, mirroring the existing map#setMaxRequestsPerHost handler).
• When unset (every normal app build), forwarding is skipped entirely: zero overhead, zero behavior change.

The native Android/iOS handlers are placeholders for now: the native API this is meant to call doesn't exist in any released version of the native SDK dependency this plugin consumes, so wiring it up for real today would break compilation. Each handler validates its arguments and no-ops, with a comment describing the exact one-line change to make once that native API ships.

What is the motivation and context behind this change?

We're adding lightweight, opt-in tagging so our own test infrastructure can distinguish traffic it generates from real user traffic. This has no effect on the public API or on any app that doesn't explicitly pass the new --dart-define.

Testing

Covered by a unit test (test/mapbox_maps_platform_test.dart) that checks both branches: no channel call when the define is absent, and a correctly-shaped call (platform#setMapboxAgentId, {'agentId': ...}) when it's present. flutter analyze, flutter test, and dart format are all clean on the touched files. An integration test (example/integration_test/mapbox_agent_id_test.dart) renders a real MapWidget and confirms it loads successfully whether or not the define is set, so this plumbing doesn't interfere with normal map creation.

Not verified: the actual outbound User-Agent header, since the native forwarding call is still a no-op placeholder as described above. Once the native handlers are wired up in a future release, header-level verification belongs in that dependency's own HTTP-layer test suite rather than here.

Pull request checklist:

• Add a changelog entry.
• Write tests for all new functionality. If tests were not written, please explain why.
• Add documentation comments for any added or updated public APIs. (N/A — no public API added; new identifiers are marked @internal.)

PRs must be submitted under the terms of our Contributor License Agreement CLA.

[CLAassistant]

All committers have signed the CLA.