Disable ftruncate_flush_race, and file the boot-timeout verdict's blind spot

[Japabu]

What

1. Disable ftruncate_flush_race in src/redlist.rs, behind its existing
   issue issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md.
   The issue gains one evidence line: red in the orchestrator's nightly for PR
   Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 at 87629411 with "the truncate did not serialise with the stalled
   flush". Status is set to expected-red, as src/redlist.rs's gate
   requires. A flaky test is disabled at once, never re-run. The issue also
   now names an owner and a machine-checkable exit condition.

2. File a harness issue,
   issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md
   (kind: tooling, owner tests/common/qemu.rs, held by the orchestrator).
   wait_for_ready reads the 16550 log back only when the ready marker is not
   the default one, so a boot that panics before virtio-console comes up —
   which writes only to the 16550 — times out with a verdict that quotes stdio
   alone and never shows the panic. Evidence: the same PR Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 control run at
   87629411 held EARLY PANIC: panicked at library/alloc/src/alloc.rs:659:9: memory allocation of 4096 bytes failed
   in its 16550 log while the verdict said only "Boot timed out". Exit: the
   timeout verdict quotes the 16550 file's tail the same way the
   Disconnected arm already does, rather than adding a second reader, shown
   by a test that stages an early panic.

Gates

gate	exit
cargo test --lib	0 (384 passed, 1 ignored)
cargo test --test toyos-build -- --list	0
cargo run -- --known-red ftruncate_flush_race	0, "YES, disabled"

🤖 Generated with Claude Code

https://claude.ai/code/session_01W6rME2DoqwjcYFStYHHY4j

[Japabu]

Review of #576 at 50b02c76. CI host passed on this head (run 36418236106, conclusion success), and the PR is not a draft. The branch changes no production code: src/redlist.rs +4, issues/ +38/−2, 3 files, +42/−2. I re-ran the host gates at this head, each exit 0: cargo test --lib (384 passed, 1 ignored), cargo test --test toyos-build -- --list (the run names the test as disabled, with its issue), and cargo run -- --known-red ftruncate_flush_race ("YES, disabled — it does not run.").

Attribution. Nothing shows the red is #572's, so this disable does not hide a regression on main:

• The issue already records reds from before Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 with the same panic ("the resize does not serialise with the metadata window"), including the arm with the kernel change reverted.
• On main-era trees the test passes: orchestrator nightlies 562r2, 562r3 and 562r4 each PASS, and all 9 recent GitHub nightly runs I pulled (36306830048, 36290616312, 36388022685, 36351950439, 36350920754, 36328646395, 36320607027, 36314576406, 36297455432) PASS.
• Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 is unmerged and touches no kernel code. The serialisation it could break is guarded at compile time by file_cache::resize(&mut Vfs, …) at kernel/src/file_cache.rs:460.
• What stays unmeasured is whether stock edk2 raises the rate at which the stimulus misses. That belongs to Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572's landing, not to this branch.

Coverage lost. This test was the only runtime witness that SYS_FTRUNCATE waits for a flush's metadata window. It was also the only host-FAT and fatgen103 check of a truncate that lands after a stalled flush. fs_truncate_persist and writeback_durability truncate with no flush racing them. The compile-time witness remains.

BLOCKER
(none)

NOTE

• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md:1 — the issue now backs a disable but has no owner and no exit condition — a disable is a compromise, and the tracker rule needs an owner, evidence and an exit for one.
• issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md:3 — kind: defect — the README puts the harness under tooling, and says defect is the OS.
• issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md:31 — "held by the orchestrator" contradicts status: open, which means nobody is holding it — pick one.
• tests/common/qemu.rs:5145 — the Disconnected arm already reads uart_log and quotes it in its panic — the harness issue's exit should reuse that path instead of adding a second reader.
• Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 — before its landing, it needs ftruncate_flush_race measured alone on stock edk2 (row lifted locally) against main. With the test disabled, nothing else will see a rate change caused by the firmware.

REMOVE

• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md:46-47 — "Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572's diff is a firmware selection change; it does not touch the VFS." — misleading: this failure depends on timing and CPU placement, and Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 changes the platform every guest boots on.
• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md:49-50 — "A flaky test is disabled at once: … says YES, disabled." — status: expected-red and the redlist row already say this. It rewrites the deleted "NOT ON THE LIST" line when that line should simply have been deleted.
• issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md:9-11 — "reads the 16550 log … back only inside the Err(RecvTimeoutError::Timeout) arm" — false: the Disconnected arm reads and quotes it too (tests/common/qemu.rs:5147-5151).
• issues/build/a-boot-timeout-verdict-quotes-stdio-alone-and-never-the-16550-log.md:17-22 — the second paragraph — it quotes a source comment word for word, which will rot. Its example verdict "nothing at all" also contradicts the evidence run, whose verdict carried firmware and loader lines.
• PR body — "so this is the same rate the issue already recorded, not a new mechanism" — the rate comes from one sample and was never measured. This becomes main's record.

LAND AFTER NAMED CHANGES