feat(📸): draw view snapshots into the texture on the GPU on Android 13+

[wcandillon]

Stacked on #526 (which is stacked on #524). The base is the #526 branch; GitHub retargets it once that merges.

Why

drawElementImageToTexture on Android renders the view through HardwareRenderer into a GPU-sampleable buffer, then reads it back (Bitmap.wrapHardwareBuffer + copy(ARGB_8888)), copies the pixels again on the native side and uploads them with writeTexture. The code already noted that the buffer could be imported directly. The missing piece was synchronization: HardwareRenderer only submits the frame, and the fence that says when the drawing is done is Image.getFence() (API 33), the same fence Dawn's Android layer feeds into beginAccess. #524 added the plumbing for that fence.

What

• Zero-copy path (Android 13+, texture with RENDER_ATTACHMENT). The renderer's AHardwareBuffer goes to native with its fence (onViewSnapshotBuffer, which takes a reference to the buffer and owns the descriptor). The queue imports it as an external texture, so BeginAccess waits on the fence on the GPU, and draws it into the destination region with the blit that backs copyExternalImageToTexture (viewport and scissor confine the render pass to destination.origin + size). The blit gains an alpha mode: opaque (video, as before), keep premultiplied, or straighten (the premultipliedAlpha: false default), applied in the encoded domain like the CPU path.
• Everything else is unchanged. Without RENDER_ATTACHMENT, before API 33, on iOS, or when the hardware render fails, the pixels are read back as before. COPY_DST stays required so the fallback always works; RENDER_ATTACHMENT is additive. The docs say so.
• Plumbing. ViewSnapshotRequest.allowFrame; PlatformContext::snapshotView(request, onPixels, onFrame, onError); ViewSnapshot.renderHardware factors the HardwareRenderer setup so both consumers (readback, hand-over) share it. A blit failure on the runtime thread rejects the promise by resolving it with a rejected JS promise (the resolve factory runs with no try/catch and cannot reject itself).
• Specs. Two new ViewSnapshot tests draw into renderable textures: the probe view at natural size, and the lime quadrant into a 16x16 region of a 32x32 bgra8unorm texture whose rest must stay zero. On the API 35 emulator they take the GPU path; elsewhere the fallback, with the same expectations.

Verification

• Android: :react-native-webgpu:assembleDebug (arm64-v8a), CMake and Java compile.
• iOS: the react-native-webgpu pod target builds for the simulator (signature change only).
• yarn tsc, yarn lint, cpplint on the touched files.
• Not run on a device here; the two new specs are the on-device check (CI runs them on the API 35 emulator).

[wcandillon]

Device round on a Pixel 8 (Android 17):

• Found and fixed (3a6a074): the GPU hand-over was never selected unless the caller passed aspect: "all" explicitly. Dawn's TexelCopyTextureInfo defaults aspect to Undefined and the converter leaves it there when the descriptor omits it, so dst.aspect == All was false; every call reached Java with allowHardwareBuffer=false. The spec passed anyway because the readback fallback produces the same pixels. The check now uses the descriptor's optional with "all" as the default.
• After the fix, both renderable-texture tests take the hand-over: the HardwareRenderer buffer arrives with a live fence fd, Dawn imports it as a shared fence, and the pixel checks still pass. The View Snapshot example with RENDER_ATTACHMENT added renders the card correctly (premultiplied alpha, ripple).
• Full e2e suite: 43 suites, 214 tests pass on the device.