fix(webgpu): request adapter's storage-buffer limit, not hardcoded 16

dom-webgpu.js capped maxStorageBuffersPerShaderStage at 16 even when the
adapter reports far more (64 in our test env). The wavefront SHADE kernel
already binds ~16 storage buffers before any user binding, so any RT
pipeline declaring 2+ user storage buffers at @group(3) overflowed the
limit and failed to build with "Too many bindings of type StorageBuffers".

Request the adapter's reported maxStorageBuffersPerShaderStage /
maxStorageBuffersInPipelineLayout instead of a fixed 16. `clamp` already
mins against the adapter cap, so baseline-only devices still get a valid
request, and the `|| 16` fallback + the `typeof cap === "number"` guard
handle limit names a browser doesn't expose (Firefox returns null for
maxStorageBuffersInPipelineLayout).

Verified in-browser: a 17-storage-buffer compute pipeline fails with the
exact reported error on a device clamped to 16, and builds cleanly on a
device requesting the adapter's 64. RTStress renders correctly.

Resolves #8

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

WAVEFRONT-DESIGN.md

@@ -66,7 +66,11 @@ maxDepth=1 (primary only). Sponza maxDepth=2 (primary + shadow).
 - [x] megakernel dead path removed (RT pipeline builds only wavefront)
 - [~] binding packing (Phase 7): SKIPPED — target device reports 64 storage
       buffers/stage (≥12), so the merge is unnecessary (issue makes it
-      conditional on <12).
+      conditional on <12). NOTE: this only holds because dom-webgpu.js now
+      requests the adapter's reported maxStorageBuffersPerShaderStage at
+      device creation (was hardcoded to 16, which left room for ~1 user
+      storage buffer and broke RT pipelines with ≥2). Devices that genuinely
+      report <12 storage buffers/stage still need this packing.
 
 ### Measured (this container's GPU, via timestamp-query; NOT a 4090)
 Per-pass GPU time, 1920×995, primary+shadow (maxDepth=2):