BTRFS "folio ... is fixup with an empty fixup bitmap" errors during heavy writes on 7.2.0; permanent writeback hang in btrfs_start_ordered_extent on 7.2.0-rc7

## Summary

Since 7.2 we hit repeated `BTRFS error … is fixup with an empty fixup bitmap`
messages under heavy write load (kernel compilation in a devtools chroot).
On `7.2.0-rc7-1-cachyos-rc` this escalated to a permanent hang: a writer task
stuck in uninterruptible D state in `btrfs_start_ordered_extent`, with the
error repeating every ~15 s for the same folio until reboot. On
`linux-cachyos 7.2.0-1` (final) the same error signature still appears
(3 occurrences during one kernel build) but writeback recovered and the build
completed. Both of the machine's two NVMe btrfs filesystems are affected, so
this is not a single-device/hardware issue. 6.18 LTS is unaffected.

Suspected area: the COW fixup infrastructure that was removed during the 7.2
merge window and restored in 7.2-rc7 ("btrfs: restore fixup worker") — the
error message comes from the restored path. The published subpage fixup
patches (locked bitmap leak / state mismatch in cow_fixup writeback,
March 2026) target sectorsize < PAGE_SIZE and should not apply here
(x86_64, 4K sectors / 4K pages).

## Environment

- Kernel (hang): 7.2.0-rc7-1-cachyos-rc (clang 22.1.8, ThinLTO)
- Kernel (errors, no hang): linux-cachyos 7.2.0-1
- btrfs-progs v7.1
- CPU: AMD Ryzen 9 9950X3D; 46 GiB RAM
- Filesystems: two separate NVMe devices, both btrfs, both affected:
- Samsung 990 Pro (`/`, subvol `/@`): `rw,noatime,compress=zstd:1,ssd,discard=async,space_cache=v2`
- Kingston Fury Renegade G5 (`/home`, subvol `/@home`, also snapper
snapshots): same mount style
- Workload: `makechrootpkg` kernel build (tens of thousands of small writes +
large link outputs) in a chroot on the affected fs

## dmesg — 7.2.0-1 final (errors, recovered)

```
[Sun Aug 23 10:57:58 2026] BTRFS error (device nvme0n1p2): root 504 ino 278142 folio 684392448 is fixup with an empty fixup bitmap
[Sun Aug 23 10:57:58 2026] BTRFS error (device nvme0n1p2): root 504 ino 278142 folio 684392448 is fixup with an empty fixup bitmap
[Sun Aug 23 10:59:08 2026] BTRFS error (device nvme0n1p2): root 504 ino 278170 folio 1109196800 is fixup with an empty fixup bitmap
```

## dmesg — 7.2.0-rc7 (permanent hang, earlier same day)

```
BTRFS error (device nvme1n1p2): root 503 ino 278109 folio 1145782272 is fixup with an empty fixup bitmap (repeating every ~15 s)
INFO: task objtool:3449408 blocked for more than 1105 seconds.
```

Stack of the hung task (`/proc//stack`):

```
[<0>] btrfs_start_ordered_extent_nowriteback+0xd6/0x160
[<0>] lock_and_cleanup_extent_if_need+0x15a/0x1c0
[<0>] btrfs_buffered_write.cold+0x39b/0xd3c
[<0>] btrfs_file_write_iter.llvm.13843955636703133873+0x59/0x100
[<0>] vfs_write+0x207/0x5c0
[<0>] __x64_sys_pwrite64+0x72/0xc0
[<0>] do_syscall_64+0xa6/0x3d0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
```

Additional frames seen in the hung-task splat: `btrfs_start_ordered_extent_nowriteback`,
`btrfs_buffered_write.cold`, `btrfs_delalloc_release_extents`.

## Reproduction

1. Boot 7.2.0 (rc7 hangs reliably; final shows errors intermittently).
2. Run a large parallel build writing to a btrfs fs (e.g. `makechrootpkg`
kernel build, -j32).
3. Watch dmesg for the fixup error; on rc7 the writer eventually blocks
forever in `btrfs_start_ordered_extent`.

## Notes

- No underlying media errors (no NVMe/controller errors in dmesg, two
independent devices affected).
- Happy to test patches or provide further debugging output.

Start at the btrfs_start_ordered_extent_nowriteback and btrfs_buffered_write entry points shown in the hung-task stack, then inspect the restored "btrfs: restore fixup worker" path. Reproduce with a parallel makechrootpkg kernel build at -j32 on Btrfs while watching dmesg for the empty fixup bitmap error. Done means the workload no longer produces the error or leaves writers permanently blocked.

Written by the indexing model from the issue text.