feat(cli): shell completions

[yanxue06]

git-semantic completions zsh > ~/.zfunc/_git-semantic
git-semantic completions bash > /etc/bash_completion.d/git-semantic
git-semantic completions fish > ~/.config/fish/completions/git-semantic.fish

bash, zsh, fish, elvish, and powershell. Generated from the same clap definition the parser is built from, so the flags a shell offers cannot drift from the flags that exist.

Named for the binary rather than the git alias — git semantic … completes through git's own subcommand machinery, which finds git-semantic on PATH.

Also here: a closed pipe no longer panics

Generating a completion script is the obvious thing to pipe, and piping it revealed that the binary panics on EPIPE:

$ git-semantic completions zsh | head -3
thread 'main' panicked at clap_complete-4.6.9/src/aot/shells/shell.rs:86:14:
failed to write completion file: Os { code: 32, kind: BrokenPipe }

Rust ignores SIGPIPE at startup, so a closed pipe turns into an EPIPE that println! panics on. search --json | head did the same thing — the two outputs most likely to be piped were the two that broke. Restoring the default disposition on unix makes the process die the way every other tool in the pipeline does.

Tests

Three new cases: every shell emits a script containing a marker unique to its own format, the script covers every subcommand, and an unknown shell is rejected with the list of known ones.

The pipe fix has no test. Whether the child hits EPIPE at all depends on losing a race against the reader's exit, and the completion script is 8 KB — well under a pipe buffer — so a test would pass without exercising anything. Verified by hand instead.

---

Second of four stacked PRs, on top of #82.