fix(standard.mk): gates accumulate instead of aborting at the first red one

[hunterdsp]

Closes #18.

Reproduced the report exactly, in a fixture with a red gate mid-list: first and red run, behind1 and behind2 never do.

The proposed patch works on three of its four claims

claim	verdict
every gate runs	✅
a failing gate still fails the run (exit 2)	✅
ALL PASS cannot print with one red	✅
gates-check is unaffected	❌ it breaks

gates-check builds its closure by walking prerequisites out of make's database:

for p in $(sed -n "s/^$$t:[ ]*//p" "$$db" | sed 's/|.*//'); do

Move $(GATES_DEPS) into the recipe and that edge no longer exists, so the closure comes back empty and every CI target reports as uncovered. gates-check hangs off lint, so that is every adopter's make lint going red on the same fetch — the exact cost this repo's CI comment says only this job can catch.

Fixed by seeding the closure from $(GATES_DEPS) itself, which makes the check independent of how gates invokes its list — what it was always trying to assert.

Also addressed from the issue's open questions

• -j: verified. make -j4 gates runs all four and still exits 2. The -k re-invocation keeps them schedulable in parallel; a shell loop over the list (the other obvious shape, and the one that would give a nicer failure summary) would have serialised them, which matters for doppler where gates include coverage and docker.
• Noise: added --no-print-directory, or every run gains Entering directory/Leaving directory around the gate output.

Gate

New CI step asserting all four properties, sabotage-checked in both directions:

• revert to prerequisites → fails with behind1 never ran
• apply -k without the closure seeding → fails with gates-check cannot see GATES_DEPS any more

Existing standard.mk CI steps re-run locally against the edited file and all still pass — including the #13 recursion guard, since -rpn still targets .std-db-goal and never runs the gates recipe.

Before merging — this publishes

Pages serves this file, and adopters compare against it on every make lint with no cache. The moment this lands, standard-check fails in every subscriber until each re-vendors. Known adopters: just-makeit (re-vendor PR ready to follow immediately) and doppler (a different working lane — needs its own re-vendor, and make lint there is red in between).

Happy to hold this until that ordering suits.

Not addressed, per the issue

glibc-check failing by design on every dev box is left alone — separable, as the issue says, and with -k it can stay honestly red without taking six gates down with it.