fix(safety-gate): close the find delete-verb gap

[tieubao]

What

Adds a find arm to safety-gate.sh so deletes expressed through find are gated the same way rm -rf already was, and extracts the build-artifact allowlist into targets_all_safe() so both verbs share one definition of "regenerable".

Why

Not hypothetical. On 2026-07-08 a disk-cleanup batch ran this, and the gate did not fire:

find <bun-global-root> -mindepth 1 -delete

The target was ~/.cache/.bun. It reads like a cache; it was actually the bun global install root, holding install/global/node_modules/ and the bin/ symlinks. It wiped the omp (oh-my-pi) cockpit. Nobody noticed until 2026-07-17, when omp update came back "command not found".

The gate is parse-aware and keys each rule on its segment's binary (SPEC-064). It had arms for rm, git and kubectl. That segment's binary was find, so it matched nothing and passed. xargs rm -rf was already covered (the wrapper-strip loop reduces it to rm); find was the hole.

How

• -delete, or -exec/-execdir/-ok/-okdir paired with an rm token, marks the segment as a delete.
• find's path operands (leading tokens before the first primary) must all be allowlisted, else block.
• Fail-closed: a find with no path operand blocks.
• The rm arm's behavior is unchanged; it now calls the shared helper.

Proof

docs/verification/find-delete-gate.md, with a runnable negative control at docs/verification/find-delete-gate-negctl.sh.

Run	Result
tests/test-hooks.sh before	469/471, exactly D1+D2 fail (gap reproduced)
tests/test-hooks.sh after	471/471
negative control	incident cmd flips 2 -> 0 -> 2 as the hook is reverted and restored; rm -rf control stays blocked throughout

D1-D5 are pinned as permanent regression tests.

Reviewer notes

Two things worth a look:

1. The reproduce script keeps its payloads inside the file, not on the command line, because the live gate otherwise blocks the harness that is testing it. Same reason the commit messages went through -F.
2. The per-step sha print is load-bearing. My first negative control used git stash on an already-committed clean file. It was a no-op, never reverted, and produced a false PASS. The sha caught it. Left in on purpose.

Known residual (deliberately not closed)

The allowlist still treats a bare relative .cache as regenerable, so rm -rf .cache is permitted, which from $HOME is the same class of mistake by a different route. The entry exists for project-local .cache build dirs, so narrowing it is a separate call with its own false-positive cost. Flagged rather than silently changed.