v0.7.4 — fix: multi-GPU rigs stuck at 0 hash/s on the H4 models

Fixes Workers stalled or crashed / 0 hash/s when mining the H4 tiers
(Qwen high / default / very-high — Qwen3.6-27B, GLM-4-9B, EXAONE-4, Kimi-Linear-48B)
on a rig with more than one GPU. Single-GPU rigs were unaffected.

What was wrong

Since the H4 hardfork, the mining models are served only by the in-process llama.cpp
engine — candle has no loader for their architectures (Qwen3.5 hybrid-SSM, etc.). But two
PoM code paths still went through candle:

1. The possession-index build parsed every tensor with candle's GGUF reader, which
   never completes on these architectures — so the GPU walk was never installed and every
   card sat at 0 hash/s.
2. The per-GPU walk only had a candle fallback for cards other than the single inference
   GPU, so on a multi-GPU rig the extra cards stalled.

The fix

• The possession-index builder now reads raw on-disk GGUF bytes (its own minimal header
  parser, no dequant) — architecture-agnostic, byte-identical result.
• New standalone raw-byte walk path (load_raw) for mining-only GPUs (and any card whose
  llama layout isn't byte-compatible), so every GPU can mine the H4 models, not just the
  inference one. The inference GPU keeps the zero-dup gather over the llama engine's weights.

No consensus/protocol change; the possession root and per-share proofs are unchanged (the
raw bytes hashed are exactly what candle used to read). The startup byte-gate and N-guard
still verify every card's gather against the canonical index before mining.

Validated

Live on a 5090 + CMP-170HX rig, --force-model high,high (Qwen3.6-27B on both): index
builds (N=516,762,688 chunks), the 5090 mines via the raw-gather path (~68 Mhash/s), the
170HX via the zero-dup path, both pass the byte-gate/N-guard, share accepted. Both cards
read 0 hash/s before this fix.

Windows/macOS unaffected. AMD carries the same fix on the next AMD rebuild.