Add opt-in encrypted dictation history

[sri-rang]

Problem

Kastword retains only the latest transcription in memory. Users cannot recover or reuse earlier dictations after another transcription or an application restart. Persisting sensitive transcription text as ordinary plaintext would undermine Kastword's privacy-first positioning and current no-history guarantee.

Expected outcome

Users can deliberately enable useful local dictation history while retaining clear control over sensitive data. History remains offline, encrypted at rest, integrity-protected, and disabled by default.

Scope

• Keep history disabled by default and require explicit, informed opt-in.
• Store transcription text and only the minimal metadata needed to present and retain it, such as a timestamp.
• Never store recorded audio as part of history.
• Encrypt history at rest using authenticated encryption.
• Protect encryption keys through an appropriate KDE facility such as KWallet.
• Fail closed when secure key access is unavailable; never silently fall back to plaintext storage.
• Add a minimal native KDE/Qt history view with copy and individual-delete actions.
• Provide configurable retention by age, entry count, or both.
• Provide a confirmed clear-all-history action.
• When history is disabled, offer to delete existing records and prevent future writes.
• Use restrictive per-user filesystem permissions and safe atomic updates.
• Document the storage location, controls, retention behavior, recovery behavior, and threat model.
• Update README privacy claims and installed documentation to distinguish the default no-history state from explicitly enabled history.

Non-goals

• Cloud storage or synchronization.
• Cross-device history.
• Audio retention.
• Rich text editing or semantic search.
• Usage analytics or telemetry.
• Claiming forensic deletion from SSDs, snapshots, swap, crash dumps, or backups.
• Protecting history from an attacker who already controls the user's unlocked session.

Acceptance criteria

• History is disabled by default, and no history database or transcript file is created before opt-in.
• After opt-in, successful non-empty dictations are available after restarting Kastword.
• Stored transcription records are not readable as plaintext and are protected against undetected modification.
• Encryption keys are not stored alongside the encrypted history as unprotected plaintext.
• Missing, locked, rejected, or failed secure-key access does not expose history or cause plaintext fallback, and provides a clear recovery path.
• Users can copy an entry, delete an entry, clear all entries with confirmation, and configure retention.
• Retention limits are enforced deterministically at startup and after inserting an entry.
• Disabling history prevents future writes and offers to delete existing records.
• History files and containing directories use restrictive per-user permissions and updates cannot leave a partially written valid store.
• Recorded audio is never written to history storage.
• Empty or failed transcriptions do not create entries.
• The history UI follows native KDE/Qt patterns and is keyboard accessible, screen-reader understandable, and localizable.
• Documentation explains that encryption at rest does not protect text copied to clipboard, pasted into applications, exposed in an unlocked compromised session, or retained by backups and operating-system facilities.
• Deterministic tests cover the disabled state, opt-in, persistence across restart, insertion, ordering, retention, individual deletion, clear-all, corruption, atomic-update failure, permissions, and secure-key access failure.

Dependencies and risks

KWallet availability and locked-wallet interaction differ across user environments. The design needs an honest, usable failure state when secure storage is unavailable. Schema migration and recovery must not risk silent data loss or plaintext leakage. Clipboard managers, target applications, backups, swap, and crash dumps remain separate trust boundaries.

Related work

Closed issue #7 established Kastword's existing privacy boundaries and no-history behavior. This issue intentionally changes that behavior only through explicit opt-in and must preserve the secure default.

Prioritization

P1: history materially improves the core dictation workflow, but it handles highly sensitive text and therefore must ship with storage protection, retention controls, deletion, and honest threat-model documentation as one coherent capability.

[sri-rang]

Show some of the recent history in Offline dictation tab; but the full history should be a separate tab of its own.

This tab can also contain the enable/disable toggle, and any other settings if required.

[sri-rang]

Approved implementation plan

Issue set: #42.

1. Add an injectable DictationHistory service and secure-key provider. Store timestamped text only, encrypt a versioned payload with libsodium XChaCha20-Poly1305, keep the random key in KWallet, use restrictive permissions and atomic writes, and fail closed on key, integrity, or storage errors.
2. Keep history disabled by default. Persist only successful non-empty transcriptions; enforce configurable age and entry-count retention (defaults: 30 days and 100 entries); support individual deletion, clear-all, and disable choices to keep encrypted data, delete it, or cancel.
3. Add a History tab after Offline Dictation with complete newest-first history, copy/delete actions, enable/disable and retention controls, storage/security status, and clear-all. Show recent entries on Offline Dictation. Preserve native KDE/Qt behavior, accessibility, keyboard use, localization, and clipboard-only copying.
4. Add KF6 Wallet and libsodium dependencies, update development/CI packaging inputs, inject fake key/storage boundaries in tests, and expand deterministic screenshots to five tab-ordered images: 01-offline-dictation, 02-history, 03-speech-models, 04-audio-input, and 05-settings.
5. Add deterministic history, controller, QML, screenshot, installation, and translation regression coverage for disabled/opt-in behavior, encrypted restart persistence, plaintext absence, integrity/key/write failures, permissions, atomicity, ordering, retention, deletion, clear-all, disable behavior, empty/error exclusion, accessibility, responsive states, and wallet-unavailable recovery.
6. Update README and installed documentation for opt-in history, storage, encryption/key handling, retention, deletion, recovery, and the limits covering unlocked sessions, clipboard managers, target applications, swap, crash dumps, snapshots, and backups.

Validation: make lint; make test; repeated focused history tests; sanitizer test build; make coverage; make screenshots with visual/privacy inspection; make install-smoke; and make validate last.

Assumptions and exclusions: no cloud sync, audio storage, cross-device history, editing, search, export/import, analytics, or forensic-deletion claims. Secure history requires KWallet and authenticated encryption and never falls back to plaintext.