[Nabzx]

Closes #264. Retention controls for #136's recording history: auto-expire by time, a configurable count cap, both independent of the existing clear-all.

Scoped down from the issue text

The issue was written expecting audio might be retained ("auto-delete audio after X days") - it isn't. #136 only ever stores the transcribed text, never the recording itself, so there's no audio-retention leg to build here. What's left, and what this PR builds, is exactly the other two asks: a time-based expiry and a configurable count cap.

What's built

• recordingHistoryStore.js: the count cap (previously a hardcoded 50) and a new time window are both read live via getRetentionPolicy, an injected adapter rather than constructor args - a change in Settings takes effect on the very next write or read, no store recreation needed. Purging runs on every write and every read, not just when a new dictation comes in - an expired entry is meant to be actually gone from disk once its window passes, not just hidden until the next record().
• Two new settings: historyRetentionDays (default 30 - the issue's own framing is that privacy-sensitive users want a real expiry on by default, not a setting to go find first) and historyMaxEntries (default 50, unchanged from before). retentionDays: 0 means never expire by time, still bounded by the count.
• Settings UI: two selects, same preset-plus-custom-value pattern as idle unload. History's own header text used to hardcode "last 50" - now says whatever the two settings actually are.

Judgement calls to veto

1. No standing background timer. Expiry is enforced lazily - on every record() and every list()/get() call - rather than a timer running for the app's lifetime. If the user sets a short window and then doesn't dictate or open History for a while, stale entries sit on disk a bit longer than the window technically allows, cleaned up the next time either happens. Given this is text-only (no audio, no live-streaming privacy exposure), I judged an always-running timer wasn't worth it for a v1. Flagging in case the "privacy-sensitive users" framing wants stronger guarantees than this.
2. Two independent limits, not one combined setting. A time window and a count cap answer different questions ("how long" vs "how many"), so they're two separate controls rather than trying to fold them into one - whichever is hit first applies.

Tests

recordingHistoryStore.test.js (+8, incl. expiry-on-record, expiry-on-read-alone, persisted purge surviving a reopen, and a live policy change taking effect without recreating the store), settingsStore.test.js (+2). Full suite (376) + typecheck + build green.

🤖 Generated with Claude Code