fix(BACKEND-ROCM): a narrow predicate makes the device-fit refusal reachable on ROCm

[joral]

Makes the #1123/#1870 load-time device-fit refusal reachable on ROCm —
the actual remaining blocker #1870 was reopened against — without moving
needs_weight_staging() or any of its other consumers.

CheckDeviceWeightFit's one call site reads target.needs_weight_staging()
to decide whether to run at all. RocmPlatform hardcodes that false — a
W0-era comment says a discrete AMD card "will eventually answer true...
Revisit at M2", never revisited despite ROCm landing grouped-GEMM, MoE
combine/gate, ROCM_ATTN and hipGraph decode capture since. Measured
directly on this box (gfx1200): VT_DEVICE_WEIGHT_BUDGET_BYTES=1 against a
real checkpoint produced no refusal at all. Meanwhile the real device
allocation the refusal exists to guard (ResidentWeight's d.b.Alloc) runs
unconditionally on any non-CPU platform since issue #125's is_cpu() fix —
so #1870's crash stayed reachable regardless of that row's arithmetic fix.

Why not just flip needs_weight_staging()

Read literally: IndexedGdnStateIoEnabled (qwen3_5.cpp) already takes
ROCm's fast arm today, independent of this flag — its non-staging branch
falls through to an op-registration check
(kCausalConv1dUpdate/kGdnDecode/kGdnStateGather/kGdnStateScatter, all
four registered for ROCm) rather than trusting the flag. Flipping it would
make this consumer take the other branch, which drops that check and just
assumes the ops exist — a regression for this one consumer, not an
improvement. MergedGdnBaEnabled/MergedGdnQkvzEnabled and the packed-decode
/ fp8-resident-prep gates have no such fallback at all: flipping the flag
would activate them on ROCm unconditionally, with no verification that the
underlying merged/packed GEMM and fp8 paths are numerically correct there.

So this PR adds a new, narrow Platform::allocates_bounded_device_memory()
instead — default-delegates to needs_weight_staging() (byte-identical for
every platform that overrides neither), RocmPlatform overrides only this
new method to true. needs_weight_staging() itself, and all six-plus of
its other GDN-dispatch consumers, are unmoved — tests pin this in both
directions. residency_policy() now carries a real, once-probed
device_memory_total_bytes via a new HIP-free vt::rocm::DeviceMemoryTotalBytes
(mirrors DeviceAvailable()'s registrar-independence reasoning; deliberately
not Backend::DeviceMemoryInfo, a live per-request probe with a different,
currently CUDA-dead consumer per issue #1126).

Real hardware, both directions, same command, same box

vllm-cli --model .../Bonsai-27B-Q1_0.gguf --device auto --max-tokens 4 with
VT_DEVICE_WEIGHT_BUDGET_BYTES=1:

• Before (stashed the fix, rebuilt): no refusal — 2.72s to reach an
  unrelated dequant error three load-stages later.
• After: refuses in 0.28s —
  device 'rocm' cannot serve this GGUF: staging its weights needs at least 3787168768 bytes (3.52 GiB) of device memory across 851 tensors, ... and this device's memory pool is 1 bytes (0.00 GiB).

Red-before/green-after on both test_platform and
test_gguf_device_fit_reach: every new case fails to compile against the
unfixed tree (stash + rebuild), both suites pass in full afterward on this
box — CPU build and, separately, a full ROCm build run on real gfx1200
hardware (17/17 cases, 133/81 assertions).

Note: an unrelated build break found along the way

A fresh CPU build of the claim base failed under GCC 15's -Werror=nonnull
in unrelated Tenstorrent debug-dump code. Filed and fixed separately as
#2021/#2022 rather than riding this branch — this PR's own local
verification applied that fix and reverted it before every commit here, so
it does not appear in this diff.

Spec: .agents/specs/rocm-device-fit-bounded-memory.md (this PR).

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-sonnet-5 [claude-code]