test(l10n): pin the metadata editor's IME next-action in zh

[gc233402-blip]

Summary

Adds the one regression test the source guard cannot express: the metadata
editor's IME next-action must survive localization.

_buildField used to pick the keyboard action by comparing the label text:

textInputAction: label == 'Title' ? TextInputAction.next : null,

Callers pass l10n.title in, so this was correct in English and silently broken
in every other locale — the label became 标题, the comparison failed, and the
Title field lost its "next" key, so the IME could no longer advance from Title to
Artist. That shipped once and was fixed in d6a6975 (#297).

This is a class A trap (a localized value used as a key), but
test/l10n/source_guard_test.dart cannot see it: the localized string reaches
_buildField through a parameter, so the evidence is at the call site and no
single-file data-flow rule reaches it. I confirmed that by restoring the exact
buggy line and watching source_guard_test.dart stay green. Only a rendered
widget catches it, so this file pins the behaviour instead of the source text.

test/features/songs/metadata_editor_ime_test.dart (3 cases):

• zh: the field labelled l10n.title has textInputAction == TextInputAction.next
• en: same, so the assertion is not locale-specific by accident
• zh: the Artist field does not claim next, or the chain Title promises is a lie

Labels are read from AppLocalizations rather than hardcoded, so the test does
not need editing when a translation changes. The zh case asserts l10n.title != 'Title' first, so it cannot pass vacuously if the locale wiring ever breaks.

Related issue

none

Checklist

• flutter analyze passes
• flutter test passes
• Rust changes: cargo test --manifest-path rust/Cargo.toml passes
• Built and ran the app if the change touches a playback path (flutter run --flavor full)
• Generated code regenerated and committed if bridge/drift/freezed models changed
• CHANGELOG.md updated for user-facing changes
• No secrets, keys, tokens, or machine-local files committed
• One change per PR; no unrelated reformatting in the same diff
• Hardware tested if the Rust audio engine or USB/DAC output changed

Notes on the unchecked boxes:

• Rust / hardware testing: no Rust, audio, or playback path is touched; the
  diff is one new test file plus nothing else.
• Generated code: no bridge/drift/freezed output changed, and no ARB key was
  added — this test reads existing keys.
• CHANGELOG.md: test-only; nothing user-facing changes.

Verification

flutter analyze: 29 issues, the same baseline as main (all pre-existing infos).

flutter test: the new file passes 3/3, and test/l10n/ plus this file pass 10/10
together.

Per the rule that a new test has to fail on the code it guards, I restored the
historical bug and confirmed the new test goes red — and only on the zh case:

Expected: TextInputAction:<TextInputAction.next>
  Actual: <null>
00:00 +0 -1: zh: the Title field keeps its IME next-action [E]

It reports the localized failure, exactly the shipped symptom. Restoring the fix
turns it green again, and injecting the bug into the bottom sheet alone still
turns it red, so it really does pin the live path: the deprecated
MetadataEditorScreen is referenced nowhere in lib/ or test/.

Local note, not a property of this PR: this machine's TEMP points into another
checkout's build/tmp, so ~43 unrelated tests fail here on a file-locking error
and on Windows-vs-POSIX path separators. That is pre-existing on unmodified
main; none of it is in test/l10n/ or this file, and CI runs on Ubuntu.