…overflow

Two failures found while benchmarking attention on Blackwell.

1. flash-attn 4 silently disables xFormers.

The `flash-attn-4` wheel installs its CuTe build at `flash_attn/cute/` with no
`flash_attn/__init__.py`, so `flash_attn` resolves as an implicit namespace
package with no `flash_attn_func`, no `flash_attn_varlen_func` and no
`flash_attn.flash_attn_interface`. xFormers gates on
`find_spec("flash_attn")` and then imports `flash_attn.flash_attn_interface`
unguarded, so `import xformers.ops` raises, `models/_utils.py` swallows it into
`xformers = None`, `HAS_XFORMERS` goes False and every fast-path model drops to
plain SDPA without a word. Measured on a B200 at seq_len 8192 with Qwen3-0.6B +
LoRA: 547 -> 2154 ms/step and 2.69 -> 19.02 GB peak.

`fix_flash_attn_4_namespace_shadow` imports xFormers once with `flash_attn`
hidden from `find_spec`, which sends it down the next branch of its own elif
chain exactly as on a machine with no flash-attn. A real flash-attn 2 install is
detected by `flash_attn.flash_attn_interface` resolving -- the exact import
xFormers performs -- so flash-attn 2 alone, and flash-attn 2 alongside
flash-attn 4, are both left untouched. Nothing is written to any third-party
package. If the repair cannot work the state is reported once with its cost.

2. Packed rows with thousands of documents abort the CUDA context.

flash-attn 2's varlen backward allocates
`dq_accum = zeros(total_q + 128 * n_seqs, n_heads, round_up(head_dim, 32))` and
indexes it with int32, so it faults with "CUDA error: an illegal memory access
was encountered" once that element count reaches 2**31 -- and that poisons the
context, so the run dies with an opaque error far from the cause. xFormers
dispatches a BlockDiagonal* bias to the same kernel, which is where it showed up.

Bisecting document count on a B200 puts the predicted limit within one document
of the observed one across seven shapes (16/128/len1: 8129, 16/96: 10838,
16/64: 16257, 8/128: 16257, 16/128/len2: ~8065, 16/128/len4: 7944, and 4/128 no
failure at all, correctly below the bound). Forward-only allocates no dq_accum
and ran clean at 20000 documents, so the guard is conditioned on a backward
being possible, keyed so gradient checkpointing picks the same backend in both
of its passes. Over the bound both varlen backends fall back to SDPA with a
one-time warning naming the cost; `UNSLOTH_DISABLE_VARLEN_INT32_GUARD=1` opts
out.

find_spec("flash_attn.flash_attn_interface") resolves the dotted name by importing
the parent first, so the classifier was executing flash_attn/__init__.py (and loading
flash_attn_2_cuda) during import unsloth on every machine with a real flash-attn 2,
including users who never touch flash attention. Probe the package's own search
locations on disk instead: same classification, a stat() instead of an import, and no
side effects. Adds a test that pins it for all four layouts.

Also point the remedy at flash-attn>=2.7.1 rather than >=2.6.3, since xformers enforces
FLASH_VER_MIN = 2.7.1 and a pinned 2.6.3 reproduces the failure the message is about,
and record the measured (~1s) width of the find_spec window instead of asserting the
process is single-threaded.

Gemma 2 hands attn_logit_softcapping to the fast kernels through flash_varlen_kwargs
only (unsloth/models/gemma2.py:157-168) and the SDPA branch of run_attention has no
softcap at all, so swapping the backend to SDPA would keep a packed Gemma 2 run alive
while training it on uncapped logits and uncapped gradients. That is worse than the
fault the guard exists to prevent, and it is reachable: at 16 heads and head_dim 256 the
threshold is around four thousand documents in a row.

When a softcap is configured, raise with the element count and the way out instead of
falling back. Everything without a softcap keeps the rescue unchanged.

They imported the module as unsloth.import_fixes, which runs unsloth/__init__.py,
which refuses to import without an accelerator. So every subprocess in the file
exited 1 on Repo tests (CPU), and check = True hid the child's stderr behind a
CalledProcessError, which is why the cause never appeared in the log.

Load import_fixes.py by path instead, in the parent and in each subprocess, and
assert on the return code with stdout and stderr attached. Verified both ways:
35 passed with a GPU visible, and 35 passed under CUDA_VISIBLE_DEVICES="".

The test that checks find_spec is restored after a failed xformers import only
intercepted xformers.ops, so on a machine without xformers installed the repair
returned early at its find_spec("xformers") gate and never warned. The Repo
tests (CPU) job collects this file and installs no xformers, so the assertion
would fail there. Serve a stub spec for the top-level package as well, which
makes the case exercise the same path with and without xformers present.

Comment text only, no code change. The measured B200 numbers, the dq_accum
formula and its int32 bound, the bisection table, the reason the classifier
never resolves a dotted flash_attn name, the two-term backward test and the
_gpu_init ordering constraint all stay.