pxx.skip's generic entries are stale — the suite under-reports by 11 tests

Generic support has moved a lot (9801b0bcb, 78e3b6426, and the specialization-alias fix behind them). The skiplist did not move with it.

Verified on seven against a compiler with srchash MATCH, so failures and passes are both conclusive.

Stale — full contract met, should be un-skipped (11)

Compile-only (%NORUN), so compiling clean IS the whole contract:

Compile and run, exit 0 — checked by running them, not just compiling:

Reason string now wrong, entry still justified (2)

tgeneric15.pp and tgeneric16.pp compile clean and fail at run (exit 1). Their reasons name a declaration/parse gap ("class inheriting from specialize TStack<Integer> as parent type"), and that half is closed. What remains is a runtime failure the reason does not describe. Same shape as tgeneric50.pp's entry naming two gaps when only one was open — an entry that is accurate about that there is a problem and wrong about what it is costs the next reader an hour.

Correctly skipped — do NOT touch (8)

• tgeneric83/84/85.pp — %FAIL tests. The contract is that the compile must be rejected; pxx still accepts them, so "it compiles" means still broken.
• tgeneric21/26.pp — accepts-invalid; needs a semantics judgement, not a compile check.
• tgeneric14/20/30.pp — wontfix: dialect-pass, deliberate divergence.

Method note, because it nearly went wrong

The first sweep just compiled every skipped generic test and reported 21 as newly passing. That is wrong for 8 of them: for a %FAIL test a successful compile is the defect, and wontfix entries are deliberate. The corrected sweep reads each file's directives and runs the non-%NORUN ones. A proxy check that ignores the contract inverts the answer for exactly the tests where the contract is the point.

Why it matters

Every stale entry is coverage we have and do not count, and a gap we may re-investigate because the list says it is open. It also feeds the noise problem in chore-t-fpc-conformance-noise-skews-priority from the other side: the suite's number is not a fair reading of conformance in either direction.

Suggested handling

Un-skip the 11 in one commit, and re-word the 2 rather than delete them. Not done here: this is a data change and the owner has this box on tickets-only. The verification above is the expensive half and is reproducible — re-run it before landing, since generics are moving daily.

Deprioritised 2026-09-02 — the Track T tooling backlog was cut as a pile

This ticket is not being called wrong. It was moved as part of a pile, not judged individually, and nothing here disputes its finding.

Owner decision. 73 of the 74 open track: T tickets were filed between 2026-08-31 and 2026-09-02, 58 on one day. The pile was too large to work through and returned almost nothing, and a ticket nobody will fix does not sit neutrally — it stays in the ranker forever at zero value, which is the argument CLAUDE.md already makes for a terminal folder over a low prio.

Four were kept in the ranker on a purely structural test — an active umbrella or a hard blocked-by: edge from live work: umbrella-one-full-tier-run-with-no-red-tier, feature-t-freebsd-image-and-runner, and the two regression-test-core-* reds that block the umbrella.

Kept, not deleted, for two reasons: so the finding is not rediscovered and refiled from scratch by the next agent who trips over it, and so it can be pulled back if what it touches becomes load-bearing.

To revive it: move it to the owning lane's backlog, set status: backlog, and say in the ticket WHAT CHANGED to make it matter now. Restoring it because it reads well is how the pile comes back.