t0xxx integration tests still have no CI coverage — they pass, so wiring them in is unblocked

[mizchi]

Summary

#201 gave the t9 range a CI job. The 30 t0xxx files are still uncovered: nothing runs them, for the same reason t9 was invisible — ci.yml's select skips its jobs for a t/-only diff, and the only task that touches t/ is test-subdir, which now filters on t9.

I ran them to find out whether that is worth fixing, and all 30 pass, so there is no cleanup blocking it:

FRESH=$(mktemp -d)
env -i PATH="$PATH" HOME="$FRESH" bash -c '
  git config --global user.name "Bit Test"
  git config --global user.email "test@example.com"
  bash t/run-tests.sh t0'

========================================
Total:  30
Passed: 30
Failed: 0
========================================

Run under env -i with an empty HOME and only the two config lines t9-suite.yml sets, so this reflects a stock runner rather than a developer machine.

Why it is worth doing

t9 went uncovered long enough for t9014 and t90010 to stay red for months (#191) and for a t9007 assertion to never pass at all since #139 (#196). Nothing structural stops the same thing happening to t0xxx; they pass today only because nobody has broken them yet.

Suggested approach

Widen the test-subdir task's filter from t9 to cover both ranges, and let .github/workflows/t9-suite.yml pick them up — renaming the job, since it would no longer be t9-specific.

Two things to weigh:

• Job duration. The t9 job takes ~14 minutes in CI, most of it the release build that deps { build } triggers. t0xxx is 30 files against t9's 21, so one combined job is the simpler shape — the build is paid once either way — but it is worth checking the total stays comfortable before committing to it.
• t0011, t0012, t0013, t0015 are randomized (t0011-random-ops.sh and friends). They pass on their seeds today; if they turn out to be flaky under CI's timing, they may want separating from the deterministic ones rather than destabilising the whole job.

Related: #202 (the harness supplies no git identity) would let the workflow drop its Configure git identity step either way.