.gitignore: the four ownership objects #868 did not reach

[ZacharyZcR]

#868 closed most of this. c/COLI_V4_UNIT_*.o covers the twelve objects the amalgamated deepseek_v4 Makefile leaves next to the sources. Four more go somewhere else:

c/Makefile:895:  V4_OWN_DIR = build/ownership

So make check also writes build/ownership/COLI_V4_UNIT_{RUNTIME,CONFIG,ST,NATIVE_QUANT}.o, which no rule matches:

$ git check-ignore -v c/COLI_V4_UNIT_CONFIG.o
.gitignore:28:c/COLI_V4_UNIT_*.o

$ git check-ignore -v c/build/ownership/COLI_V4_UNIT_ST.o
(no match)

On current dev, a clean checkout plus make check still leaves ?? c/build/ in git status — one git add -A away from exactly the accident #868 was written to stop, and the one I made on #849 and #800.

c/build/ wholesale rather than four names: nothing under it is tracked (git ls-tree -r dev -- c/build/ is empty), it is a build output directory, and naming each object would need editing every time the ownership suite grows.

One thing worth stating, since it cost me a round trip on #849

An ignore rule does not untrack what is already committed. #868 made those twelve objects invisible in git status while leaving them in the tree — git ls-tree still listed all sixteen on my branch after rebasing onto current dev. What removed them was git rm --cached, which @JustVugg named in his first comment before the follow-up suggested the rebase would be enough.

Same shape as #835, where c/.gitignore already named tests/bench_omp_grain and the binary sat tracked regardless. Ignore rules prevent; they do not clean up. This PR is prevention only — nothing under c/build/ is tracked today, so there is nothing here to remove.

Verified both directions: the four objects are ignored after this change, and git status on a tree with c/build/ownership/*.o present is clean.

[OPS-NeoRetro]

APPROVED!!! 👍

[JustVugg]

Right, and thank you for catching it rather than working around it.

c/COLI_V4_UNIT_*.o is a single-segment glob — it never crosses a directory, so it took the twelve in c/ and left the four V4_OWN_DIR = build/ownership puts in a subdirectory. Twelve of sixteen.

What makes this worse on my side: when I committed the cap fix I had to clean the same sixteen out of git add -A by hand, and I removed all sixteen without noticing that the rule I had just written only covered twelve. I fixed the symptom on my commit and left half the cause standing, then told you on #849 that the gap was closed.

Ignoring the whole c/build/ is the better call than a tighter glob, and I checked before merging: nothing tracked lives under it. A narrow pattern would miss whatever the Makefile puts there next, which is precisely the mistake I just made.

Merged. #849 and #800 are genuinely clear on a rebase now, rather than clear-ish.