fix(rocm): guard the four remaining custom-kernel launchers

[inureyes]

Refs #1885, #1814, #1801.

Issue #1885 fixed this defect at the two sampler launchers. The same shape survived at four more: a two-valued dispatch whose false arm still meant "Metal" rather than "no port for this backend", so a direct call on ROCm took the Metal arm and fast::metal_kernel threw across a noexcept cxx extern, ending the process.

Classifying all ten dispatch sites mechanically found them: five were already guarded by #1803 and #1885, four were not, and the MoE launcher is reached through two bridge entry points. The guards reuse the shape paged_attention_decode established, placed before the port is selected so the message names the backend rather than the port that happened to be tried, and five bridge declarations become Result in the same change, because a guard without that conversion only changes which abort message prints.

Each guard was checked against its production gate before being added, since a guard above a reachable path would turn a working graph fallback into a throw. fused_add_rms_norm_available() and fused_rope_qk_append_available() are custom_kernels_available(); ssm_kernel_available() is cu::is_available(), which is the no-CUDA stub on a ROCm build; fused_moe_enabled() folds in the port predicate. All four answer false on ROCm, so production takes its graph path and never reaches a guard.

The ten callers split three ways, and the split is deliberate. The MoE sites use .ok() because the function wrapping them returns Option and "the fast path does not apply" is already its contract, so a direct call on a portless backend is legitimate rather than a defect. The SSM, layers.rs and parity-test sites use expect because each already gates on the support predicate, so an error there means the gate and the launcher disagree, which should fail loudly instead of being folded into a fallback.

Two comments this change made false are corrected rather than left to mislead. fused_moe_enabled() justified its port term with "its bridge function does not return Result", which was true under #1803 and is not now; the term stays, for the cheaper reason that deciding early beats building the call to have it refused. fused_add_rms_norm_eligible() claimed the launcher's exceptions are not recoverable, which now holds for contract violations but not for a missing port.

Validated on gfx1151: the full ROCm gate is unchanged at one failing target, the nvfp4 abort of #1806, with that abort the only terminate called in the run. A probe confirmed the refusal by running it, returning [fused_add_rms_norm] no custom kernel port for this GPU backend as a typed error rather than aborting. CUDA and Metal are unreachable from every new path, since custom_kernels_available() is true there.

The ten dispatch sites

Classified mechanically rather than by reading, so none was missed.

Guarded already	Unguarded, fixed here
gumbel_max_sample (#1885)	fused_add_rms_norm
rejection_sample (#1885)	fused_rope_qk_append
paged_attention_decode (#1803)	ssm_update_kernel
paged_attention_decode_v2_partial	run_fused_moe_two_kernel
paged_attention_merge_states

run_fused_moe_two_kernel is reached through two bridge entry points, so five declarations become Result, not four.

Evidence

The refusal, run rather than inferred:

custom_kernels_available = false
fused_add_rms_norm: Err -> [fused_add_rms_norm] no custom kernel port for this GPU backend; mlxcel's callers take the graph fallback instead

Full ROCm gate, unchanged from before this branch:

error: 1 target failed:
    `-p mlxcel-core --lib`
aborts: 1

That one is the nvfp4 abort of #1806. cargo fmt is clean, and cargo clippy -p mlxcel --lib --tests -- -D warnings, the command CI runs, is clean.

Worth noting how two of the ten callers were found. cargo check passed on them, because ignoring a Result<()> is the unused_must_use lint rather than a type error, so only the -D warnings clippy surfaced them. Both are decode hot-path callers in layers.rs.

Next

Every guard here is a placeholder that says "no port". The ports themselves are #1814, and the path is already open: fast::hip_kernel exists in the ROCm overlay and #1862 proved the three-arm switch with BitNet.