feat(gpu): name the algebraic hashes on the device dispatch, loudly

[MauroToscano]

What

• The three algebraic StarkHash configurations (RpoStarkHash, RpxStarkHash, PoseidonStarkHash) now compile under cuda. AlgebraicBatchBackend and AlgebraicPairBackend implement DeviceTreeBackend, keyed by the new AlgebraicHasher::COMMITMENT_HASH; the StarkHash impl reads that same constant, so a configuration's name and its device key cannot be edited apart. The cfg(not(feature = "cuda")) fork around the configurations, their inhabitation check and their tag test is gone.
• math_cuda::DeviceHash gains Rpo256 / Rpx256 / Poseidon twins. No kernels exist for them yet, so every device dispatch site carries a third arm, unimplemented!("{hash:?} device commit not yet ported (<site>)"). Never a byte-hash fallback: a tree labelled RPO is built by RPO kernels or not built at all (HASH-PINNING.md).
• gpu_lde.rs bridge: device_hash_for / commitment_hash_for are total const fns in both directions, plus a const round-trip assertion. A CommitmentHash variant without a DeviceHash twin, or a cross-paired arm, fails to compile at the bridge with a message naming the gap. Verified by breaking it: Rpx256 => DeviceHash::Rpo256 fails with E0080 at the assertion.
• config.rs: the device tie-in was a never-called closure, so its value comparison never ran. It is now a const block that evaluates (verified to fail when broken). algebraic_commit.rs carries the same check for its three configurations.
• hash_pin.rs (doc only): a "cuda on an algebraic pin" section. Such a build compiles and aborts at its first device commit; neither a compile_error! nor a fallback belongs there.

Loud-arm sites (lane K's phase-2 checklist)

file	line	function	site
crypto/math-cuda/src/lde.rs	1057	build_inner_tree_levels_for	inner tree levels
crypto/math-cuda/src/lde.rs	1144	coset_lde_row_major_inner	row-major row-pair leaves
crypto/math-cuda/src/lde.rs	1342	coset_lde_row_major_split_trees	row-major row-pair leaves, column range
crypto/math-cuda/src/lde.rs	2157	coset_lde_batch_base_into_with_merkle_tree_inner	column-major base leaves (tuple arm)
crypto/math-cuda/src/lde.rs	2402	evaluate_poly_coset_batch_ext3_into_inner	comp-poly ext3 leaves
crypto/math-cuda/src/fri.rs	208	FriCommitState::fold_and_commit_layer	FRI layer ext3 leaves
crypto/math-cuda/src/fri.rs	227	FriCommitState::fold_and_commit_layer	FRI layer inner tree levels
crypto/stark/src/gpu_lde.rs	1425	try_build_comp_poly_tree_gpu	comp-poly tree from ext3 evals
crypto/stark/src/gpu_lde.rs	1474	try_build_comp_poly_tree_gpu_from_dev	comp-poly tree from resident slabs

Porting a family means replacing these nine arms with launches. Every match on DeviceHash is exhaustive, so a new dispatch site cannot omit the arm.

Evidence

Box A, at 3e2a0cc (this branch sits on per-table-gpu @ fc9f1e1, after #956; the tip a42554c (#953) touches no file this PR touches):

• make lint: D2_LINT exit=0
• math-cuda parity: blake3_fused_parity ok. 3 passed, merkle_root_parity ok. 3 passed, comp_poly_tree ok. 4 passed, one_lde_buffer ok. 3 passed; 1 ignored
• make test-cuda-integration: ok. 7 passed ... 13.41s
• make test-cuda-d1: ok. 1 passed ... 2.62s

Laptop, stub cubins: cargo clippy -D warnings -A clippy::op_ref on math-cuda, stark --features cuda and lambda-vm-prover --features cuda (--lib --tests) green; cargo check -p lambda-vm-prover --lib --tests (non-cuda) green; cargo fmt --check clean.

Behaviour to know

Under cuda an algebraic pin now compiles and aborts, naming the hash and the site, at the first device commit of any table at or above the GPU LDE threshold. Proving a block under an algebraic pin on GPU requires the kernels, not a fallback. No proof-format change: CommitmentHash variants and order and the 32-byte node are untouched, and the byte-hash device paths are unchanged (parity above).

Follow-ups recorded by the coordinator: F2 (the lfm/mod.rs not(cuda) test-module gates), step 6c (hash-rpo's compile_error! and the HASH-PINNING §CUDA rewrite).