feat(arrow) convert colors

[ibgreen]

Goals

• Add a reusable path for converting Arrow and GPU color vectors into tightly packed normalized Uint8 RGBA GPU vectors.
• Support Uint8, Float16, and Float32 RGB/RGBA inputs through the current GPUData, GPUDataView, and evaluator APIs.
• Normalize deck.gl Arrow layer color props without taking ownership of caller-provided GPU buffers.

Changes

• Added and exported convertArrowColors, convertColors, canConvertColors, and ArrowColorType from @luma.gl/arrow.
• Added the convertColors GPGPU operation over GPUData/GPUDataView inputs, with chunk-preserving GPUVectorEvaluator integration and canonical unorm8x4 output.
• Added CPU conversion, a WebGL CPU/readback fallback, and WebGPU compute conversion.
• Preserved byte offsets, byte strides, GPU vector chunk boundaries, and caller-owned source buffers.
• Added Uint8, Float16, and Float32 RGB/RGBA color support to ArrowPathLayer, ArrowPolygonLayer, and ArrowTextLayer color props. Nested per-vertex colors remain RGBA8-only.
• Updated text model selection to follow device GPU text-expansion capability when storage rendering must fall back to attributes.
• Replaced the import-only Node test wrapper with the actual .node.spec.ts suite.
• Clarified that WebGPU Float16/Float32 readers decode IEEE bit patterns from a shared word-addressed storage binding rather than numerically converting uint values.

Verification

• nvm use
• yarn lint fix
• yarn build
• yarn test
  • 188 Node tests passed; 8 skipped.
  • 1,258 headless browser tests passed; 25 skipped.

Docs

[Pessimistress]

What's this for?

[ibgreen-openai]

It was only a Node test-discovery shim that imported the shared suite. There is no separate browser suite to share here, so I removed the wrapper and moved the actual tests directly into convert-colors.node.spec.ts.

[Pessimistress]

Why do you need to read a float as uint?

[ibgreen-openai]

The source storage binding is word-addressed (array<u32>) so one shader can read packed Uint8, Float16, and Float32 rows while honoring byte offsets and strides. The uint is only the raw storage word: Float16 uses unpack2x16float and Float32 uses bitcast<f32>, so there is no numeric uint-to-float conversion. I renamed the readers to make the bit-level behavior explicit and added a WGSL comment explaining it. For Float16x3, the Arrow adapter uses the byte-identical Uint16x3 storage layout because VertexFormat has no Float16x3 entry, while inputFormat retains the Float16 interpretation.

[Pessimistress]

As discussed, deck.gl layers already expect color attributes to be normalized, so theoretically they should not reject a float32 input.