btrfs: stripe_alloc: charge the preallocation's stripe hold under the reservation...

btrfs: stripe_alloc: charge the preallocation's stripe hold under the reservation lock

A preallocation is admitted for round_up(bytes, stripe) against the
whole-stripe supply and then holds one stripe in bytes_stripe_margin
until its allocations land, but the hold was added by the caller after
btrfs_alloc_data_chunk_ondemand() returned: __reserve_bytes() recorded
only the raw bytes in bytes_may_use and dropped space_info->lock in
between.  Two sub-stripe preallocations admitted in that window each saw
the other's raw bytes only, both passed against one stripe of supply,
and a buffered write admitted alongside them could find no stripe at
writeback.  The delalloc path does not have this gap (its margin is
probed into bytes_may_use with the bytes and kept there); make the
preallocation path the same.

Charge the hold inside __reserve_bytes(), in the critical section that
grants the bytes -- for a direct admission and for a ticket granted
later by btrfs_try_granting_tickets() -- and hand it back through a new
btrfs_alloc_data_chunk_ondemand_held() /
btrfs_reserve_data_bytes_held() to the four preallocating callers
(fallocate's range loop, zero-range, relocation's cluster preallocation,
the encoded write).  The release is unchanged.  Found by review
(2026-09-15); prealloc-race-test.sh (eight fallocate() storms against
buffered writers at the fill edge) did not reproduce the window in six
rounds before the change and stays clean after it.

Assisted-by: Claude:claude-fable-5-1