clj-paren-repair-claude-hook mangles Yocto BitBake .bb recipes (extension collision with Babashka)

## Summary

The hook treats every `.bb` file as Babashka and runs the Clojure formatter over it. But `.bb` is also the extension for **Yocto / BitBake recipes**, and applying Clojure paren-repair to one mangles its syntax in a way that silently breaks the build minutes after it starts.

## Concrete failure

In a Yocto recipe for a PyPI package, the standard form is:

\`\`\`
SRC_URI[md5sum] = "..."
SRC_URI[sha256sum] = "..."
\`\`\`

`SRC_URI[flag] = value` is BitBake's variable-flag syntax. After the hook ran on a freshly-written recipe, both lines came out as:

\`\`\`
SRC_URI [md5sum] = "..."
SRC_URI [sha256sum] = "..."
\`\`\`

— a single space inserted between `SRC_URI` and `[`. My read is that the formatter parsed `SRC_URI[...]` as a Clojure function call where `[...]` is a vector literal, and "fixed" the apparent missing whitespace between the function symbol and its arg.

BitBake does NOT tolerate that whitespace despite the visual similarity. The build fails at parse time:

\`\`\`
ERROR: ParseError at .../python3-cta2045_0.1.0.bb:11:
unparsed line: 'SRC_URI [md5sum] = "1d855b8d9215b822e810756c919e9dfd"'
\`\`\`

Cost me a failed Buildkite run before I traced it.

## Why the collision is real

- **Babashka:** `#!/usr/bin/env bb` Clojure scripts, often saved as `script.bb`. The hook's allowlist legitimately wants these.
- **Yocto / BitBake:** recipes live at `recipes-//_.bb`. Bigger projects (any Linux distro, every embedded device shop using OpenEmbedded) have hundreds of these per repo. They share zero syntax with Clojure.

Both communities have established `.bb` for years, so this is just a fact-of-life clash for an editor hook to handle.

## Proposed fixes

Either of these would disambiguate near-perfectly:

1. **Shebang check** — if the file starts with `#!` and the interpreter ends in `bb`/`babashka`, run the formatter; otherwise skip. Babashka scripts that lack a shebang exist but are rare; BitBake recipes that have one essentially don't.

2. **Path check** — skip files matching `recipes-*/*/.+\.bb$` (the canonical BitBake recipe layout, near-universal in OE/Yocto trees). Lower-effort and handles ~99% of real cases.

3. **Heuristic content sniff** — skip if the file contains BitBake keywords like `inherit`, `SRC_URI`, `LICENSE = "CLOSED"`, `RDEPENDS:`, etc. Most paranoid; probably overkill if you already do (1) or (2).

(1) seems cleanest to me — single check, language-agnostic, low false-negative.

## Reproduction

\`\`\`
# In any directory:
cat > test_0.1.0.bb <<'INNER'
SUMMARY = "test"
LICENSE = "MIT"
inherit pypi

SRC_URI[md5sum] = "deadbeef"
INNER

# Trigger the hook (e.g. via Claude Code Write tool on this file).
# After: SRC_URI gets the bad space inserted.
\`\`\`

## Environment

- macOS 25.5 (Darwin)
- Claude Code with PostToolUse hook configured on `Edit|Write`
- hook installed via `bbin install`, currently at git SHA `401e2746d1dea1d29cd9e69c35f22e844e104c2d`

Happy to PR a fix if a direction is welcome — let me know which of the three approaches you'd take and I'll wire it up.

Start at the Claude Code PostToolUse hook's .bb allowlist and reproduce the issue with test_0.1.0.bb using the BitBake content shown. Done means BitBake recipes are skipped without preventing legitimate Babashka .bb scripts from receiving paren repair.

Written by the indexing model from the issue text.