btrfs: stripe_meta: do not steal from the global reserve below the relocation reserve

btrfs: stripe_meta: do not steal from the global reserve below the relocation reserve

With the whole-stripe reserve in place the fill stopped cleanly at the
edge: 374 MiB claimable, the reserve plus margin plus the outstanding
reservations, no canary, no abort.  Then the test deleted half of its
tiny files, and every unlink that the gate refused came back through
the global reserve steal, which does not look at stripes.  Deleting an
inline file is pure COW churn under stripe_meta: it frees no stripe,
since the leaf it lived in stays, and each transaction of unlinks takes
fresh stripes.  Metadata used did not move by a megabyte while the
claimable supply went from 374 MiB to zero, and the next commit aborted
with the canary ("claimable 0 open 1490944 trapped 1506082816").

Refuse the steal once the claimable supply is down to the relocation
reserve plus the claim margin.  The unlink fails with ENOSPC, which is
recoverable, instead of the abort, which is not, and the reserve stays
with the background relocation that is the only thing that turns
trapped space back into whole stripes.

Assisted-by: Claude:claude-fable-5