`bt trace hook` returns exit code 0 on every tested failure path, making caller-side failure detection impossible

[LuizNascimentoTR]

Summary

We tested bt trace hook under 16 distinct conditions: malformed/empty stdin, missing required JSON
fields, no daemon reachable with --no-spawn, unknown --source, missing environment variables
needed to resolve a route, and an empty credential store. In all 16, the process exited 0. (4 usage
errors — unknown flag, missing flag value, unknown subcommand — correctly exited 2; that path is
fine.)

This means nothing downstream (a coding-agent hook runner, a CI step, a human watching the terminal)
can tell a genuine failure apart from success by exit code alone. Combined with a fail-open
integration design, a whole class of failures becomes invisible unless someone happens to check the
dashboard.

Scope of this claim

This is an enumeration over 16 tested conditions, not a proof of exhaustive behavior — we are not
claiming bt trace hook can never exit non-zero, only that in every condition we tried, including
ones that plausibly should fail loudly (empty credential store, unreachable daemon), it did not.

Suggested fix

Reserve a distinct, documented non-zero exit code for genuine delivery/resolution failures, separate
from the fail-open "don't block the coding session" behavior — e.g. still exit 0 by default for
CI-safety, but support an opt-in strict mode (env var or flag) that surfaces failures via exit code
for callers that want it.