Add hooks: vibestretch (resubmission of #5780 with corrected safety and privacy notes)

[Eliasjunit]

Resubmission of #5780, closed with a review I agree with: two of the entry's own
claims did not survive contact with what the plugin ships. Both are fixed here.

1. safetyNotes — the statusline skill does edit settings

Was: "Writes nothing outside its own state directory and never modifies your project or your settings."

The hook script's writes really are confined to $STATE_DIR, but the plugin also
ships skills/statusline/SKILL.md, and that skill wraps or installs a statusLine
command under ~/.claude. Opt-in, disable-model-invocation: true, backs up
first — and still a settings edit. Now stated:

The hook writes only to its own state directory. The optional /vibestretch:statusline skill, when you run it explicitly, edits your ~/.claude configuration and backs it up first.

2. privacyNotes — the payload is read, just not kept

Was: "Prompt and tool content is never read. Only timestamps and elapsed seconds are recorded."

The script reads the first 4 KB of the hook payload to pull session_id out of
it, and on PostToolUse that window contains tool input and output. Nothing from
it is retained or transmitted, but "never read" and "never recorded" are not the
same sentence, and on a privacy note the difference is the point. Now stated:

Reads the first 4 KB of the hook payload to extract session_id. Nothing from prompts or tool output is retained or transmitted; only timestamps and elapsed seconds are stored.

3. scriptLanguage metadata

Corrected bash → sh, matching the #!/bin/sh shebang and the existing
"A POSIX shell" prerequisite.

Provenance

scriptBody is byte-identical to scripts/vibestretch.sh at
v0.7.1 (288
lines — four more than in #5780, from a fix released today) and copySnippet is
byte-identical to hooks/hooks.json. Both were verified by extracting them back
out of the .mdx and diffing against the repository files, not by eye.

The troubleshooting section additionally notes that VS Code's integrated terminal
discards the notification sequence silently — that was the fix in v0.7.1, found
when a tester ran the plugin there.

Thank you for the review; it was specific enough to act on directly.