feat: post transcription hook scripts can consume transcription text

[jhsu]

Adds an explicit consume protocol for post_transcription_hook.

Hooks can now exit with status 77 to indicate that they handled the transcription and that hyprwhspr should not paste it.

Changes

• Added explicit preserve, replace, and consume hook outcomes.
• Exit code 77 skips clipboard, paste, and auto-submit behavior.
• Preserved existing behavior for:
  • Exit 0 with stdout: replace transcription
  • Exit 0 with empty stdout: preserve transcription
  • Other failures: preserve original transcription

[goodroot]

Looks good to go!

Quick one though, I'd appreciate your thoughts:

When a hook consumes the transcription, inject_text returns True, which is the same signal used for "actually pasted."

Both callers key off that bool: main.py logs "[INJECT] Text injected..." and clears mic/recovery state, and longform shows the success OSD and clears the session.

That's cool as a pipeline-health signal (the hook ran fine), but it's not completely accurate as an injection signal.

We might want a third return type to indicate consumed.

WDYT?

[jhsu]

@goodroot yeah i think that'd be a good idea and clear what is happening.
How do you see different return signals being used aside from better logging/debug?

[goodroot]

Hmm yes. Wondered if you might have some insight here.

Now "consume" reuses the same success chime/flash as a real paste. In the case of voice commands rather than dictation, they'd probably want a distinct cue: "command executed" vs. "text pasted".

(e.g. "open terminal" → hook dispatches an action, consumes the text so it doesn't get pasted as literal characters)

Anywho, I don't think that's worth blocking this PR for, but if you had any input, I would be keen to hear it.

I'm going to merge it. Thank you very much. I'm going to think for a day or two before I bump the version, though, on how to treat this case.