fix(🌎): avoid implicit web canvas resize

[huytdps13400]

Summary

• stop the web canvas wrapper from silently changing its drawing-buffer dimensions on every window resize
• preserve initial DPR-aware sizing through the existing MakeWebGPUCanvasContext path
• leave subsequent buffer resizing to the renderer/app so dependent depth and MSAA attachments can be recreated atomically

Fixes #351.

Root cause

The wrapper listened to window.resize and changed canvas.width / canvas.height after a 100 ms debounce. WebGPU canvas resizing invalidates the current texture, but renderers such as Three.js still owned depth/MSAA attachments at the previous dimensions. The next render pass therefore mixed textures of different extents and failed validation every frame.

The browser regression reproduced the current issue exactly: resizing the example viewport changed the drawing buffer from 2400×1344 to 1800×744 while Three.js kept its 2400×1344 depth attachment.

Verification

• Current main RED: Three.js InstancedMesh emits repeated attachment-size validation warnings after a 1200×800 → 900×500 viewport resize.
• Patched GREEN:
  • CSS canvas size changes from 1200×672 to 900×372.
  • Drawing buffer remains 2400×1344 until the renderer explicitly resizes it.
  • Zero attachment-size warnings.
  • The scene continues rendering after resize.
• tsc -p packages/webgpu/tsconfig.json --noEmit
• targeted ESLint and Prettier checks
• yarn workspace react-native-webgpu build
• root yarn tsc: 3/3 workspaces pass
• git diff --check

The example asset hook was temporarily bypassed only for browser setup because the current web example cannot resolve its Metro asset IDs; that harness change was fully reverted and is not part of this PR.

[wcandillon]

Thanks a lot for this :)

[github-actions]

🎉 This PR is included in version 0.8.5 🎉

The release is available on:

• v0.8.5
• GitHub release

Your semantic-release bot 📦🚀