Make the coverage ratchet a required status check on develop

[TaprootFreak]

#4385 adds a Coverage ratchet job to the PR workflow. It pins 399 files at 100% on all four metrics and fails when any of them regresses. The job publishes its result as a check, but develop has no required status checks configured, so a red ratchet does not block a merge. Until the check is required, the gate rests entirely on a reviewer noticing the red mark.

Why this is not part of #4385

Required checks are a repository setting, not a change to a file, so they cannot ship in the same pull request that adds the job.

Precondition: let it prove itself first

The ratchet makes the whole test suite a precondition for 399 coverage numbers. Any nondeterminism anywhere in that suite — a test skipped depending on state, a load-sensitive assertion — can push a pinned file below 100 and produce a red required check that has nothing to do with the change under review. A flaky required check is worse than no check, because it teaches the team to ignore red.

#4385 already replaced one such assertion (the wall-clock parallelism test in bitcoin-fee.service.spec.ts), but that is one example, not evidence about the remaining suites.

Suggested sequence:

1. Merge Guard every already-covered file with a repo-wide coverage ratchet #4385 and let the ratchet run advisory for a while — roughly two weeks or 20 pull requests.
2. Record every red run and whether it was caused by the change under review.
3. If it stayed clean, add Coverage ratchet to the branch ruleset for develop as a required status check.

Scope

• Observation window completed, unrelated failures recorded (if any)
• Coverage ratchet added as a required status check on develop
• Decide whether the other PR jobs should become required at the same time, so the ratchet is not the only blocking one

Related: #4385