journal log: preflight the transcriber toolchain at record-start, not after recording #82

Context

journal log (the mic-toggle / hotkey flow) preflights ffmpeg before it starts recording (cmd/log.go:200, checkFfmpegAvailable), so a missing recorder fails fast. But the transcriber toolchain — the whisper.cpp binary (exec.LookPath, internal/log/transcribe.go:103) and the model file (os.Stat(modelPath), internal/log/transcribe.go:76) — is only checked inside Transcribe(), which runs in the detached pipeline after the recording has finished.

Result: a user who has ffmpeg but not whisper.cpp/the model can record a full note, stop, and only then hit the failure. PR #81 makes that failure at least visible (a ✕ journal log failed notification), but the recording is already spent.

Proposed change

Add a lightweight transcriber preflight to the record-start path (alongside checkFfmpegAvailable): verify the whisper binary resolves and the configured model file exists before spawning the recorder. On failure, refuse to start and surface the same actionable message (run \journal models pull`` / install whisper.cpp) via terminal output and a desktop notification, so the hotkey user learns immediately — before losing a recording.

Keep it injectable (a checkTranscriberAvailable var mirroring checkFfmpegAvailable) so tests never depend on a real whisper install. The direct journal log <audio.wav> path already surfaces the error inline, so this is specifically about the record-start flow.

Acceptance criteria

• Starting a recording with a missing whisper binary or model fails fast (no recorder spawned, no lockfile written) with an actionable message + notification.
• Existing ffmpeg preflight behavior unchanged.
• New preflight is injectable; a table test covers present/missing-binary/missing-model.

Out of scope

• Bundling whisper.cpp or auto-pulling models.