A pull's check that fails while the check machine's disk is under its free floor is the machine's red, not the pull's: it is neither reworked nor parked #5453

For: a full disk on the check machine has sunk unrelated pulls at least twice this week (#5339, #5411; pulls #5406 and others), and builders correctly found nothing to fix. src/checks/shared_red.ts only spares a pull when three pulls fail the same test within the hour, so a single disk-full red still parks the pull and strikes its issue.

Done:

• [ ] When a pull's check finishes red, the check service records the free fraction of the check machine's disk (statDisk in src/kernel/vitals.ts) on the run. If it was under DISK_FREE_MIN, the red is the machine's: the crew neither reworks nor parks the pull. It waits and re-runs the check once the disk is back above the floor, just as a shared red waits for main's next green (find where src/crew/dispatch.ts consults sharedWithPulls and add this beside it).
• [ ] The vitals carry one card, "the check machine's disk was full when N checks failed", in place of a park per pull. Its sentence names the free percentage.
• [ ] Tests (a new test/checks-disk-red.test.ts, with the disk reading injected as plain data):

- a red check recorded under the floor is not parked or reworked, and re-runs when the reading is above the floor; - a red check above the floor is treated exactly as today; - the card appears once for several such checks. Each fails without the change.

• [ ] Before pushing, run the new test, test/shared-red.test.ts and bun x tsc --noEmit.

Files: src/checks/service.ts (record the reading), src/crew/dispatch.ts, src/kernel/vitals.ts (the card), test/checks-disk-red.test.ts. Risk: never treat a green check differently. Keep the floor the existing DISK_FREE_MIN, not a new constant. Why the disk fills is a separate question for whoever runs the machine.