test_the_uncovered_record_only_shrinks pins equality, not direction — MAX_UNCOVERED_READS has risen 27 to 45 #17650

A guard named "only shrinks" pins equality, and the ceiling it guards has risen five times

repo_tests/python_filter_covers_its_guards_test.py:240,
test_the_uncovered_record_only_shrinks, asserts:

assert len(uncovered) == MAX_UNCOVERED_READS

Equality, not monotonicity. Raising the ceiling passes, provided matching entries are added in the
same commit. The guard is working exactly as written — and what it is written to do is not what its
name says.

Meanwhile repo_tests/glob_declared_reads_15900_test.py:21 states the invariant as fact, and uses it
to justify a design decision:

MAX_UNCOVERED_READS only ever goes down, so expansion forces either a 59-entry cap raise or
widening the filter to .github/workflows/** — twelve shards on almost every pull request.

Measured: it has gone up five times

Value at each commit touching repo_tests/python_filter_uncovered_reads.py, oldest last:

27 → 45. One decrease, five increases. Nothing failed, because nothing checks the direction.

Why this is worth fixing rather than re-wording

The equality pin is genuinely good and should stay — its own docstring gives the reason, that headroom
under a ceiling is room for a new bypass to appear with nothing failing. The gap is that no check
compares the new value to the previous one. So the number that is supposed to be a one-way ratchet is
in practice a free variable, and every raise looks identical in review to a lowering.

This is the same family the repo has been finding all week: a guard whose name and docstring claim
more than its mechanism enforces, where the reader's belief comes from the name and the tree's
behaviour comes from the assert. Sibling instances: #17640 (inline-code stripping), #17649 (26 direct
store writers past a chokepoint), #15826 (the class), and the it.each( counting fault.

Acceptance criteria

• Either the guard enforces the direction it names — the value may not exceed the value on the
  merge base — or the name and both docstrings are corrected to say equality pin, and the
  guard(ci): the filter-coverage checker ignores glob-declared reads, so its green over-claims #15900 rationale that depends on monotonicity is revisited.
• If direction is enforced, a deliberate raise needs an explicit, reviewable escape with a stated
  reason, not silence. Five raises have already happened and were presumably each justified; the
  criterion is that the justification is recorded, not that raising is forbidden.
• Mutation proof: a commit that raises the ceiling and adds matching entries fails the
  direction check, and one that lowers it passes.
• The claim at glob_declared_reads_15900_test.py:21 is true of the tree, or removed.

Not established

Whether any of the five raises was wrong. Each added matching entries and each may have been correct.
This issue is about the absence of the check, not about the history — and the history is only
visible because the absence was looked for.