[flutter_tools] Validate optional parameter names in gen-l10n - #193417

In flutter gen-l10n, the keys of a placeholder's optionalParameters map were written into the generated NumberFormat constructor call as named arguments (gen_l10n.dart, '${parameter.name}: ${parameter.value}') without any validation. A crafted key in any ARB file, including a translated locale whose template is benign, could close the constructor call and inject arbitrary Dart statements; the issue shows the result still analyzes cleanly. The values were already safe: numbers are written as is and everything else goes through generateString.

This PR rejects optional parameter names that are not valid Dart identifiers with an L10nException while parsing the placeholder, the same way #192434 validates placeholder types. Keys that are not identifiers either failed to compile or only worked by accident (a name padded with whitespace, such as "decimalDigits "); they now fail with a clear message. No ARB in this repo uses such a key.

The issue suggests an allowlist of the named parameters each NumberFormat constructor supports. A single identifier cannot close the call, so the identifier check already stops the injection, and a wrong but valid name is still reported by the analyzer; an allowlist would additionally tie the tool to intl's constructor signatures.

The new test uses the reproduction from the issue: a benign en template and an es translation whose optionalParameters key injects a print statement. Before the fix setupLocalizations generated the localizations without complaint; now it throws L10nException.

Fixes #193327

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 in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• 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.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.