why: Pin hook firing semantics per load path and the stop command's
behavior.
what:
- Load CLI tests for start/restart hook dispatch and append behavior
- Stop command tests including on_project_stop execution
- Builder and config tests for exit/stop hook metadata
- util tests for run_hook_commands

why: Give users working references for lifecycle hooks and the stop
command.
what:
- CLI page and API autodoc page for tmuxp stop
- Lifecycle hook sections in top-level configuration docs
- Example workspace file for lifecycle hooks

why: Lifecycle hook commands may contain expanded credentials, so
normal logs must not persist the command text.
what:
- Replace hook command log extras with a redacted placeholder

why: Pin that hook failure logging keeps exit codes without leaking
command text.
what:
- Assert redacted placeholder in hook log extras and absence of the
  raw command string

why: The prose claimed all hooks block tmuxp, but on_project_exit runs
via tmux's client-detached hook after tmuxp has returned — the claim
was false for one of the four hooks and contradicted the per-hook
table on the same page.
what:
- Name the three blocking hooks explicitly and describe
  on_project_exit's deferred, non-blocking dispatch

why: run_hook_commands logs records under tmux_hook_cmd, but the key
was absent from the structured-context table that downstream
consumers treat as the schema contract.
what:
- Add the tmux_hook_cmd row to the core key table

why: The command text is redacted because hooks may expand
credentials, but the failure path logged the hook's raw
stdout/stderr at debug — the same secrets leak through output.
what:
- Replace raw output debug logging with a single suppression record
  carrying tmux_stdout_len / tmux_stderr_len companion fields
- Add parametrized coverage asserting an echoed secret marker reaches
  no log record while the length fields remain attributable