fix: reliability batch 0B — collision-resistant dictionary IDs + reference-aware history deletion

[GalaxyRuler]

Before Submitting This PR

• I have searched existing issues and PRs to ensure this isn't a duplicate
• I have read CONTRIBUTING.md

Stacked on #78 (Batch 0A). Base is codex/reliability-batch-0a; retarget to main after #78 merges.

Human Written Description

This is the data-integrity half of the reliability batch. Two things that were quietly corrupting existing user data: dictionary entry IDs collided (Arabic-only phrases all slugged to the same value, and same-millisecond batches shared a timestamp, so deleting one entry could delete several), and reprocessed history rows shared a WAV file with their parent so deleting either row killed audio the other still needed. Both are fixed without dropping any existing data.

What's in the batch

1. Collision-resistant dictionary IDs + v2 migration. New allocator appends a deterministic numeric suffix on collision (snippet-module precedent, no new deps), wired through every ID-creation path. A dictionary_schema_version v2 migration repairs already-persisted duplicates in place: first occurrence keeps its ID, later duplicates get suffixed, array order and all other fields preserved, idempotent. Migration persists via forced immediate save and rolls back version/cache if the save fails (the 0A ambiguity-rejection guard remains the runtime backstop).
2. Reference-aware history deletion. One shared helper now deletes the DB row first, then removes the WAV only when its last referencing row is gone. Routed through every cleanup path (single/batch delete, count retention, time retention, clear-all). Transform rows stay non-owning; a file-delete failure after a successful row delete is logged, not fatal.

Testing

• Full Rust suite: 739 passed, 0 failed (implementation session + independent review session).
• tsc, ESLint, Prettier, cargo fmt --check, translations: all pass. No deps/lockfile/frontend-string changes.
• Installed-product device verification on WhiteKnight (real hardware lane):
  • v2 migration through a real app launch → kill → relaunch: schema=2, dict_shared / dict_shared-2, order preserved, stable across restart.
  • Real recorded-WAV cycle via TTS→VB-CABLE→Whisper: reprocess yields 2 rows sharing 1 WAV; deleting parent-first keeps the WAV until the child is also deleted, and deleting child-first keeps it until the parent is also deleted. 15/15 steps green.

AI Assistance

• AI was used (please describe below)

If AI was used:

• Tools used: Codex (implementation), Claude Code (audit, adversarial review, code review, WhiteKnight device verification)
• How extensively: implementation and review AI-driven from a human-approved plan; both items code-reviewed against spec and device-verified on real hardware before push

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 070ee0a3dd

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Report failed WAV deletion after dropping the row

When clear_recordings or clear_history hits a permission/IO error removing the last WAV, this branch only logs it and still returns failures: []. The frontend treats an empty failures list as success, so users can be told recordings/history were cleared while the orphaned audio file remains on disk until a later reconciliation attempt, which can fail for the same reason. Please keep adding a HistoryDeletionFailure for these non-fatal file errors even though the DB row is already gone.

Useful? React with 👍 / 👎.