fix(compute): chunk bulkUploadF32 to stop wedging the GB10 driver (#106)

[dndungu]

What

Fixes #106. bulkUploadF32 consolidated all eligible f32 tensors into one
device allocation + one H2D copy. At CrossAsset sample-upload scale (~213k
tensors → multi-GB) that single large cudaMalloc/cudaMemcpy wedges the
GB10 (sm_121) driver in an uninterruptible ioctl: the worker thread sits in
D-state, the container becomes unkillable, and podman exec/logs/rm all
hang (this also drove the recurring orchestrator pod-leak).

Change

Upload in bounded chunks: cap each device allocation + copy at
bulkUploadF32MaxChunkBytes (64 MiB) / bulkUploadF32MaxChunkTensors (4096),
appending each chunk buffer to bulkUploadBuffers. Preserves the
few-round-trips win over the per-tensor path; the resulting GPU storage views
are byte-identical to before.

Chunk-boundary math is extracted into a pure bulkUploadChunkRanges helper and
unit-tested on CPU (no GPU required): tiling (no gaps/overlaps), both caps, a
lone-oversized tensor getting its own range, and the 213k-count production case
splitting into bounded chunks.

Test

• go test ./compute/ -run TestBulkUploadChunkRanges — green (CPU).
• go build ./..., go vet ./compute/ — clean.
• Existing TestGPUEngine_UploadWeights_BulkPath unchanged (small input still
  collapses to one chunk → one buffer).
• GB10 end-to-end verification (Wolf train-crossasset, full 213k-tensor upload)
  is being run downstream; will post the result.

Notes

bulkUploadF32MaxChunkBytes is a var so a test (or caller) can force the
multi-chunk path with small inputs. Caps are conservative (a prior per-tensor
smoke at ~16k tensors worked; 64 MiB / 4096 leaves wide margin under the
observed wedge threshold).

[dndungu]

⚠️ Verification FAILED — do not merge as a fix yet.

Built Wolf train-crossasset against this branch (4eaae4b, no vendoring — the chunked code is in the binary) and ran the matched repro (full COIN bars, 213,304-tensor pre-upload on GB10). It wedged identically: after reaching the upload, podman exec + log streaming + ssh/logind all hang while the orchestrator control plane stays responsive — the same uninterruptible D-state CUDA-driver wedge from #106.

So capping each alloc/copy at 64 MiB / 4096 tensors did not prevent the wedge. The failure point is therefore not (only) the single large cudaMalloc/cudaMemcpy this PR chunks — it's somewhere not yet pinned (possibly the first CUDA op of the upload regardless of size, the per-tensor loop after bulkUploadF32, the ~213k SetStorage view creations, or the first kernel touching the data).

Holding this PR until the exact wedging cgo frame is captured (persisted /proc kernel-stack dump that doesn't depend on the wedged data-plane). The chunking is still a reasonable defensive bound, but it is not the fix on its own. Will update #106 with the pinned frame.