fix(hooks): RepeatDetection injects warning via stdout, not stderr+exit 2

[brycemagera]

Problem

RepeatDetection.hook.ts is a UserPromptSubmit hook. On a >=60% similarity match it calls process.stderr.write(...) then process.exit(2).

For UserPromptSubmit hooks, exit code 2 blocks and erases the prompt, and routes stderr to the user only -- the model never receives the message. Two consequences:

1. The repeat-detection warning the hook is designed to inject into the model's context never arrives there.
2. The user's resent message is silently dropped -- the model never sees it.

The file header comment states the hook "injects a high-priority WARNING into the model's context forcing re-reading of the user's message." The implementation does the opposite of that intent.

Fix

The correct channel for UserPromptSubmit context injection is exit 0 with the text on stdout -- stdout from a UserPromptSubmit hook is appended to the model's context, and the prompt proceeds normally.

This swaps process.stderr.write -> process.stdout.write and process.exit(2) -> process.exit(0) in the trigger branch. Detection logic (the 0.6 threshold, tokenizer, and trigram similarity) is unchanged. 7 insertions, 4 deletions, one file.

Testing

• bun build on the hook: clean.
• Behavioral: with the fix, a >=60%-similar follow-up arrives intact with the warning prepended as context -- verified via synthetic UserPromptSubmit stdin and live in a Claude Code session. Before the fix, the same message was erased before reaching the model.

Reference

Claude Code hooks documentation, UserPromptSubmit exit-code semantics: exit 2 blocks/erases the prompt with stderr shown to the user only; exit 0 stdout is added to the model's context.

[ryan-baum]

Production confirmation, plus the full causal chain for why this PR matters well beyond restoring the hook's intent: #1143 (comment)

Short version: in SDK channels (the v5 Telegram/iMessage Pulse modules), this hook's exit-2 doesn't just fail to warn — it silently erases the user's prompt (numTurns: 0, cost: 0, empty result), which is the root cause behind the "Sorry, I wasn't able to generate a response" reports in #1143 / #1284 / #1281. The telegram module's history-prepend makes consecutive prompts 60–98% Jaccard-similar, so once a conversation gets going, every message trips the 0.6 threshold and gets dropped before the model runs. On my instance, 13/13 fallback responses across four days correlate 1:1 with "UserPromptSubmit operation blocked by hook" entries in the session transcript.

stdout + exit(0) is the hook's documented intent — the re-read warning has never actually reached the model in any channel until this change.