* feat: add configurable Whisper language candidates
* fix(settings): defer language candidate edits and tolerate list config
The candidates entry applied settings on every keystroke, restarting the
whisper.cpp model per character, and edits typed while an apply held the
guard were dropped so the saved value could differ from the entry. Defer
application like the initial prompt: mark edits dirty and apply on page
change or close; _finish_auto_apply re-applies edits that landed mid-apply,
and _persist_pending_text_edits saves them if the dialog closed first.
A JSON list in config also crashed the dialog on open because
Gtk.Entry.set_text needs a string; populate the entry through the engine's
_normalize_language_candidates so both stored forms render the same text.
* fix(recognition): validate whisper.cpp language candidates before selection
auto_detect_language's probability map names every language the model can
return, but candidate selection scored configured codes against it with a
0.0 default, so a typo or "auto" could still win the max() and reach
transcription. Only codes present in the probability map are eligible now;
unsupported codes are logged and skipped, and when none qualify the
unrestricted detection result is used instead of forcing a code the model
never scored.
Also add the missing input annotation on _normalize_language_candidates.
* fix(settings): persist deferred text edits off the GTK main loop
_finish_auto_apply runs on the main loop and called
_persist_pending_text_edits synchronously, so reconfigure() restarted
the model in-process and froze the UI when the dialog closed mid-apply.
Run the reconfigure + config save on a worker thread, matching the
normal apply path.
Also annotate _on_language_candidates_changed's signature.
* fix(settings): guard deferred saves and annotate new candidate tests
* fix(settings): reconcile the engine to winning settings after a mid-restart apply
* fix(settings): drop superseded deferred edits instead of saving them
A dialog closed mid-apply stashes its pending text edits for a worker to
persist after the running apply finishes. The worker's mtime check could
not tell the in-flight apply from a newer one started in a reopened
dialog, so the older snapshot could reconfigure the shared engine and
save over the settings that won.
Serialize applies and the deferred persist on a shared lock and order
them with a generation counter bumped when an apply begins. The worker
now skips reconfigure and the save entirely when a newer apply has
begun, and skips the restart when the running apply already landed the
same values.
* fix(settings): merge deferred text edits per key instead of dropping them
Closing the dialog mid-apply stashes the typed prompt/candidate values
with the apply's generation. When a reopened dialog applies newer
settings first, the generation check used to discard the whole stash —
losing the closed dialog's edits even where the newer apply never
touched those keys.
Persist keeps a pre-edit baseline per key: after a newer apply lands,
only keys it actually changed are dropped; the rest still reconfigure
the engine and save, so a stale value can never reach the shared engine
while untouched edits are no longer lost.
* refactor(settings): narrow deferred-edit persist exception with context
* chore: retrigger ci
---------
Co-authored-by: Jatin K Malik <jatinkrmalik@gmail.com>
