fix(lyrics): prevent Bengali romanizer crash on mixed-script text

[YuriNachos]

Description

BengaliRomanizer.romanize(_:) could trap with Fatal error: String index is out of bounds when a line mixed Bengali with another non-Latin script the Bengali-locale tokenizer cannot transcribe (e.g. a Bengali lyric line containing a Thai/CJK/Hangul/Arabic word). The fallback branch indexed the Swift String by grapheme cluster (text.index(_:offsetBy:)), but CFStringTokenizer token ranges are measured in UTF-16 code units. Bengali matras (combining marks) make the grapheme count smaller than the UTF-16 count, so the UTF-16 location overshoots endIndex and the process traps. This harmonizes the romanizer with its ThaiRomanizer / JapaneseRomanizer siblings, which already index via NSString.

AI Prompt (Optional)

🤖 AI Prompt Used

Investigate and fix an indexing crash/mis-romanization in BengaliRomanizer.
Verify the bug at HEAD before fixing (instrument the real CFStringTokenizer
loop; do not infer from source). Mirror the correct Thai/Japanese romanizers:
add `let nsText = text as NSString` and extract fallback tokens with
`nsText.substring(with: NSRange(...))` so the unit matches the CFRange. Do not
change transliteration tables or the sibling romanizers. Add a pure-logic
Swift Testing case that is RED at HEAD and GREEN after the fix, plus a
pure-Bengali control and an emoji passthrough guard. Run the project gate.

AI Tool: Claude Code

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Related Issues

Changes Made

• BengaliRomanizer.swift: capture let nsText = text as NSString and extract the fallback (non-transliterable) token via nsText.substring(with: NSRange(location:length:)) instead of grapheme-cluster String indexing, matching ThaiRomanizer/JapaneseRomanizer.
• RomanizationTests.swift: add BengaliRomanizerTests — a cross-script crash regression (বাংলা ก, RED→GREEN), a pure-Bengali control, and an emoji passthrough guard.

Testing

• Unit tests pass (swift test --skip KasetUITests)
• Manual testing performed (instrumented tokenizer to confirm RED crash + GREEN output on macOS 26)
• UI tested on macOS 26+ (n/a — pure-logic romanization change)

RED (HEAD): romanize("বাংলা ก") traps — Swift/StringCharacterView.swift:158: Fatal error: String index is out of bounds (signal 5). GREEN (fix): returns bānlāก; full suite green.

Checklist

• My code follows the project's style guidelines
• I have run swiftlint --strict && swiftformat .
• I have added tests that prove my fix/feature works
• New and existing unit tests pass locally
• I have updated documentation if needed
• I have checked for any performance implications
• My changes generate no new warnings

Screenshots

n/a — no UI change.

Additional Notes

• Crash trigger is cross-script non-Latin text, not emoji/symbols. An emoji like ❤️/👋 is emitted by CFStringTokenizer with a LatinTranscription equal to itself, so it takes the transcription branch (not the buggy fallback) and already worked. The crash requires a token that is emitted without a Latin transcription — i.e. another non-Latin script the bn locale can't transcribe (Thai ก, CJK, Hangul, Arabic). Verified empirically by instrumenting the tokenizer.
• The regression test's assertions are deliberately limited to the crash contract (no trap + intact Bengali run) rather than asserting the raw foreign character: LatinTranscription availability can vary across macOS versions and CI spans macOS 15 + 26, so asserting the raw glyph would be OS-fragile.
• A separate, intentionally out-of-scope behavior: word-unit tokenization drops non-word symbols like ♪/♫/★ (they aren't emitted as tokens). That is a tokenizer-emission characteristic, not the indexing bug fixed here, and is left unchanged.

[YuriNachos]

Heads-up on the red macOS Unit Tests (macos-26) check, so it does not read as a problem with this branch: the only failing test is WebKitCookieRestoreTests … Persisted archive replaces stale live authentication cookies, which is in the cookie/auth layer — unrelated to the Bengali romanizer change in this PR.

It fails only on macos-26; on the same commit macOS Unit Tests (macos-15) passes, and macOS UI Tests passes on both macos-15 and macos-26, as does build/SwiftLint/SwiftFormat. Nothing in the romanizer path can affect cookie restoration, so this looks like a macos-26 runner/WebKit behavior difference rather than a regression here. Happy to rebase/re-trigger once the workflow is healthy.