Untrack the bench binary my own PR committed

[ZacharyZcR]

c/tests/bench_omp_grain is a 16,880-byte ELF executable, mode 100755, tracked in dev. It was added by 00129d2 (#808) — mine — and it is the only tracked build artifact under c/tests/.

The gap, not just the file

.gitignore already guards test binaries properly:

c/tests/test_*
!c/tests/test_*.c
!c/tests/test_*.cu
!c/tests/test_*.mm
!c/tests/test_*.py

That pattern was never extended to bench_* or fuzz_*, which build to extensionless binaries in the same directory. So this fixes the gap rather than the one file — same shape, same source exceptions, for both prefixes. Verified both directions: the binaries are ignored, and bench_omp_grain.c / fuzz_rans.c are not.

After this, git ls-files c/tests/ has no extensionless entries left.

Why it matters beyond tidiness

This interacts with #801. tools/clean.py today globs only tests/test_*.exe, so make clean removes nothing on Linux or macOS. #801 fixes that. The moment it lands, make clean would delete a tracked file and hand every contributor a dirty tree — a confusing failure whose cause is here, not there.

Removing the binary is what keeps that fix harmless, so this is worth taking regardless of what happens to #801.

Note on how it got in

#808 added bench-omp-grain, whose recipe builds tests/bench_omp_grain in-tree. git add picked it up because nothing ignored it. The irony is not lost on me — #808's stated purpose was running structural checks in CI, and it shipped an artifact no structural check was looking for.

[ZacharyZcR]

Found the missing half of this story while rebasing #819, and it makes the case for git rm --cached rather than an ignore rule.

c/.gitignore already ignores this binary, and has since the day it was committed. I added the line myself, in 4dbada9, the same series that added the binary:

c/.gitignore:  tests/bench_omp_grain

So this was never "forgot to ignore it". It is the older trap: .gitignore has no effect on a path git is already tracking. The rule went in, git kept tracking the file anyway, and the ignore silently did nothing — which is also why nothing downstream ever flagged it.

That changes what the fix has to be. An ignore rule alone cannot remove this file no matter where it is written; only git rm --cached can, which is what this PR does. The .gitignore work here is for the next one — c/tests/bench_* and fuzz_* in the root ignore file, so a future bench_* binary is never staged in the first place.

Worth noting the two ignore files were both already trying: c/.gitignore named this exact path, and the root .gitignore guarded c/tests/test_* with source exceptions but stopped there. Two rules pointing at the problem, neither able to fix it after the fact.

I have left the c/.gitignore line alone — it is correct, it was simply never sufficient on its own.