Reinstate the torch GPU path, if it still earns its place

[jhollway]

Parked on feature/torch-gpu while the architecture settles. Reinstate with git revert 14b6739.

Why it was parked

gpu_batch_ols() ran only where the family is gaussian and there were no random effects, no fixed effects, and no multinomial comparison. It was 318 lines in R/qap_gpu.R, duplicated for CSS, plus a 24-line gate in each engine — and it had no test.

No hosted runner has a CUDA device, so it cannot be exercised in CI at all. Meanwhile having {torch} in Suggests broke the build: torch installs as an R package before its Lantern backend is downloaded, so torch::cuda_is_available() throws rather than returning FALSE, and the CPU fallback aborted instead of falling back.

What it needs before coming back

• Decide whether it is needed at all. Measure it against the "build the design matrix once" work first: under permute = "outcome" the model matrix is constant across every draw, so decomposing it once and solving for each permuted outcome may make the GPU unnecessary at the sizes users actually have.
• If it stays: widen it beyond gaussian, or document plainly that it is gaussian-only.
• A test asserting that on a machine with a CUDA device the GPU path gives the same p-values as the CPU path for the same seed. That test cannot run in CI, so it needs a manual checklist.
• Keep the guard already fixed on the branch: gpu_available() must survive a {torch} installed without its backend.

Benchmarks to beat

Sequential, on one laptop:

Network	permute	200 permutations	Implied 1,000
60 nodes	predictor	1.7 s	9 s
200 nodes	predictor	10.5 s	53 s
448 × 12,489 two-mode	predictor	345 s at 10	~9.6 h

The last row is the network from #4. That is the case a GPU would help, and also the case the design-matrix work would help.

Order

Third, and conditional. It should not come back before the performance work in the roadmap says whether it is still worth having.