Fixes two related GPU-decimation problems on large scenes, plus a fail-loud robustness change.
Problems

• The edge-cost kernel packed all spherical-harmonic coefficients into a single storage buffer, which exceeds WebGPU's ~2GB per-binding limit (maxStorageBufferBindingSize) at ~11.2M splats with 48 SH columns — decimation crashed with appearance buffer … exceeds device maxStorageBufferBindingSize.
• A device out-of-memory (hit on an EC2 NVIDIA instance) was swallowed: WebGPU reports OOM asynchronously, so the failed allocation left buffers zeroed, the k-NN graph came back empty, and simplifyGaussians silently returned its input. In the streamed-SOG LOD chain (each level decimated from the previous) this cascaded into several identical full-resolution levels with a clean exit code.
  Changes
• Split the appearance buffer into up to three ≤16-column chunks (variable width, so partial chunks store no padding) and merge positions+scalars into one buffer, keeping the kernel at 8 storage buffers (the WebGPU baseline). Raises the per-binding cap from ~11.2M to ~33.5M splats at 48 SH columns, and ~59.6M for DC-only inputs.
• Upload edges per dispatch batch (256KB) instead of the full N·k list, removing them as a per-binding cap and cutting ~1.6GB of VRAM at 13M splats.
• Centralize GPU error handling in the device factory (uncapturederror + device-lost): log the precise cause and escalate to a non-zero exit, so every GPU consumer fails loudly instead of writing degenerate output.
• simplifyGaussians now throws if it cannot reach the target (zero k-NN edges or no finite-cost pairs) at any iteration, instead of returning a partial or full-resolution scene.
  Verification
• GPU output is byte-identical to the previous version on real scenes (910K and 3.3M splats); the chunking and edge-batching changes are behavior-preserving.
• CPU decimation suite passes (41/41); the no-progress guard throws on degenerate input and the centralized handler logs + fails on a forced GPU error.
• Could not reproduce a real device OOM locally (ample memory), so the OOM path is verified via the error-scope/handler mechanism and the no-progress backstop rather than an actual OOM — re-running the failing .splat on the EC2 instance is the end-to-end confirmation.