poll device readiness before formatting sticky disk

[devin-ai-integration]

Summary

Fixes a race condition where mkfs.ext4 /dev/vdb fails with "Device size reported to be zero" after a Firecracker drive hot-swap.

Root cause: Firecracker's PATCH /drives is host-synchronous — it returns once the backing file is swapped on the host. The guest kernel learns the new capacity via an async virtio config-change interrupt. When the gRPC response reaches setup-docker-builder and it immediately runs mkfs, only ~50ms may have elapsed — not enough for the guest's virtio-blk driver to update the device geometry.

Fix: Add waitForDeviceReady(device) at the top of maybeFormatBlockDevice that polls blockdev --getsize64 until the device reports non-zero size (50ms interval, 5s timeout). This is deterministic — it waits exactly as long as the kernel needs, no more.

+async function waitForDeviceReady(device: string): Promise<void> {
+  // poll blockdev --getsize64 until size > 0 (50ms interval, 5s timeout)
+}
+
 async function maybeFormatBlockDevice(device: string): Promise<string> {
+  await waitForDeviceReady(device);
   // ... blkid check, mkfs.ext4
 }

Observed in FastActions/fa#4268 CI — 51ms between PATCH /drives/2 completing on the host and mkfs.ext4 failing in the guest.

cc @brucemakallan

Link to Devin session: https://app.devin.ai/sessions/45a3be2102b746d393226ba6fec5b390

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled. (Staging)}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring