feat(models): wire the published Vulkan exports and bump nativeLibsVersion

[msluszniak]

Description

Wires the 44 Vulkan .pte files published under the HF v0.11.0 tag: style transfer (4), YOLO26 detection (15), YOLO26-seg (15), YOLO26-pose (3), RF-DETR detector/segmentation/keypoint, FastSAM s/x, BlazeFace and SDXS. They become the Android default through the existing variants resolution.

New URLs resolve through NEXT_VERSION_TAG (v0.11.0), since a tag carries only the files cut under it and each model's older exports stay on VERSION_TAG.

nativeLibsVersion moves to 0.10.4: its core carries the constant-segment fix without which RF-DETR fails to load (0x23), and its Vulkan backend is 1.8-3.8x faster on Mali for the conv models added here.

FEATURE_MAP and the native-libraries doc gain vulkan for objectDetection, keypointDetection, instanceSegmentation, styleTransfer, textToImage and segmentAnything.

Five published Vulkan exports are deliberately not wired, because each measured slower than the Android default it would replace: efficientnet-v2-s (fp32 export, 2.4x slower than XNNPACK int8 on Adreno), selfie-segmentation and its landscape checkpoint (1.2x slower on Adreno), lraspp (0.86x vs int8 on Adreno) and ssdlite320 (loses on both GPUs).

Introduces a breaking change?

• Yes
• No

Type of change

• New feature (change which adds functionality)

Tested on

• iOS
• Android

Testing instructions

Every one of the 44 URLs was HEAD-checked against HF for a 200 and a plausible content-length. yarn workspace react-native-executorch test (4082 tests), tsc --noEmit and yarn lint pass; the registry's own modelVariants invariants cover the Android default resolution.

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

[barhanc]

I tested selected models from each model family and they work correctly. One note that might be important is that on S20+ I didn't observe any speedup compared to xnnpack version and in some cases Vulkan is noticeably slower (e.g. FastSAM S ~800ms on cpu vs ~1s on Vulkan).

I guess we can merge it after conflict resolution.

[msluszniak]

I tested selected models from each model family and they work correctly. One note that might be important is that on S20+ I didn't observe any speedup compared to xnnpack version and in some cases Vulkan is noticeably slower (e.g. FastSAM S ~800ms on cpu vs ~1s on Vulkan).

I guess we can merge it after conflict resolution.

You didn't observe any speedup at all on any model, or there were some models with regressions and no speedup on s20+?

[barhanc]

Some models were slightly faster, e.g. the Yolo variants across different tasks (on the order of ~10% and the speedup was stable and consistent). I didn't observe any huge speedups (like the CoreML vs xnnpack case on iOS) and on the large models e.g. FastSAM vulkan was slower + I observed that the UI (of the whole phone not just the app) was slightly laggy when the heavy inference was running (probably because of using the same GPU resources as rendering).

[barhanc]

@msluszniak I've added the S20+ benchmark harness results to #1363 PR comment and they also seem to reproduce the general behavior:

• Vulkan Supertonic is noticealby slower than xnnpack (~5.6s vs ~5s).
• Similar speed regression on large Whispers.
• On small model like PaddleOCR there is a speedup of the order 10-20%.