fix(ohos): decode Canvas images into SDR shared memory

[bytemain]

Summary

• tone-map OHOS Canvas/cache images to SDR
• request RGBA_8888 output
• force shared-memory PixelMaps on API 15+
• preserve Kuikly's API 12 floor with a weak allocator symbol and a validated legacy decode
• fail closed when the Canvas-compatible decode policy cannot be satisfied

Root cause

On HOP-AL10, a 2160x3840 HDR JPEG (sHdr:4) decoded successfully into a hardware/surface-buffer PixelMap (memType:4) after GetByteCount pixelFormat 0 error, but the Kuikly editor rendered it as black. The cache path previously requested IMAGE_DYNAMIC_RANGE_AUTO and the system-selected allocator.

Both editor consumers converge on this cache: rememberAsyncImagePainter and rememberAsyncImageBitmap use KuiklyImageCacheManager, which calls MemoryCacheModule.cacheImage. In OHOS native render, KRMemoryCacheModule::GetImage() has one external consumer: KRCanvasView::DrawImage; ordinary KRImageView does not consume image_cache_map_. This makes CPU-readable output a Canvas-cache contract rather than a global ArkUI Image policy.

Decode policy

API 15+:

• IMAGE_DYNAMIC_RANGE_SDR tone-maps HDR before allocation
• PIXEL_FORMAT_RGBA_8888 removes the unknown/HDR pixel format
• OH_ImageSourceNative_CreatePixelmapUsingAllocator(..., IMAGE_ALLOCATOR_TYPE_SHARE_MEMORY, ...) prevents a hardware/surface-buffer result

API 12-14 compatibility:

• the API 15 allocator symbol is weak-linked, matching Kuikly's 5.0.0(12)+ load floor
• the legacy decoder runs only after the same SDR/RGBA options are accepted
• image info must report non-HDR RGBA_8888 with valid dimensions/stride
• OH_PixelmapNative_ReadPixels must copy the complete row-stride buffer successfully, proving CPU readability
• any mismatch/read failure releases the PixelMap and fails closed; there is no HDR AUTO fallback

Validation

• candidate exact fe7ce7724296849a3932678571fbcbd6322593ce
• DevEco OHOS aarch64 clang++ syntax compile PASS
• object-symbol check: allocator decoder is w (weak undefined); API12 decoder and ReadPixels are ordinary supported imports
• root/submodule diff-check PASS
• parent mobile source-contract verifies the weak API gate, validated API12 fallback, both editor consumers, and rejects HDR AUTO regression
• fresh exact matrix is running for this amended head; prior exact is superseded

Product gate

Physical validation remains in mobile task #41: the same HDR sample plus an ordinary SDR JPEG control must pass preview, edit, save, upload, restart/restore, and process-liveness checks on HOP-AL10.