feat: bulk dictionary import via paste or file upload

[NathanSkene]

Summary

• Adds "Import" button to the Custom Dictionary view (both empty and populated states)
• Opens a dialog with a textarea for pasting words and a file upload button (.txt, .csv, .json)
• Live preview shows new word count and duplicate count before confirming
• Parses input by splitting on newlines, commas, and tabs to handle all common list formats
• Adds i18n translation keys for all new UI strings (English; other locales use fallback defaults)

Closes #460

Test plan

• Open Settings → Custom Dictionary (empty state) → verify "Import" link appears below example tags
• Click Import → paste multi-line words → verify preview shows correct counts → confirm adds words
• Click Import → upload a .txt file with one word per line → verify words are parsed and added
• Click Import → upload a .json file with a string array → verify words are parsed and added
• Verify duplicate words are skipped (add some words first, then import a list containing some of them)
• Verify words persist after closing and reopening the app (localStorage + SQLite sync)
• Verify Import button also appears in the populated state (next to "Clear all")
• Verify Cancel button closes dialog without adding words

🤖 Generated with Claude Code

[JiwaniZakir]

The handleFileUpload callback has no file size guard before calling reader.readAsText(file) — a user dropping a multi-megabyte .txt or .csv file will synchronously block the main thread while it's parsed into the textarea. A simple early return when file.size exceeds a reasonable limit (e.g. 1 MB) would prevent that.

The parsedImportWords, existingSet, newImportWords, and duplicateCount computations run on every render of DictionaryView regardless of whether the import dialog is open. For users with large custom dictionaries, rebuilding the Set and filtering on every keystroke in the main word input is unnecessary work — wrapping these in useMemo (gated on importText and customDictionary) would scope that cost to when it actually matters.

In handleFileUpload, the JSON branch only handles the case where the parsed value is a top-level array. A common export format is { "words": [...] } or similar; right now that silently falls through to dumping the raw JSON string into the textarea, which will confuse users. A comment or a slightly broader check (e.g. looking for a words/dictionary key) would make the failure mode less opaque.

[NathanSkene]

Rebased onto current main and addressed review feedback:

• Added 1MB file size guard before readAsText
• Wrapped import preview computations in useMemo
• Added support for { "words": [...] } JSON format

[NathanSkene]

Manual validation status note:

This PR remains in the keep/merge set. During the broader validation pass I did not uncover a blocker or regression here, and the branch is already rebased with the earlier review feedback addressed.

Current upstream-facing status from my side:

• still intended to merge
• not superseded by the later validation work
• no active review-thread blocker remains on the PR at the moment

I have not done the same intensive end-to-end packaged-app validation on this one that I did for the recording/audio branches, so this comment is mainly to clarify merge status rather than claim new feature-specific test coverage.