hal/vulkan: add OpenHarmony surface support

[ozongzi]

Connections

Related to #9158 (GLES sRGB issues, mainly on OpenHarmony). This does not fix that
issue, but it gives OpenHarmony users a Vulkan path instead of leaving them stuck on
the GLES backend.

Description

The Vulkan backend has no OpenHarmony window-system integration, so create_surface
fails there and GLES is the only backend that works. That rules out anything needing
VERTEX_STORAGE or compute, even though OpenHarmony devices ship a working Vulkan
driver and the platform provides VK_OHOS_surface.

Three changes:

• desired_extensions now asks for VK_OHOS_surface on target_env = "ohos". That
  list already gets filtered against the available instance extensions, so a driver
  without the extension just drops it and surface creation fails later with a clear
  message, rather than breaking instance creation.
• create_surface_ohos builds the surface from the OHNativeWindow that an
  XComponent hands out. raw-window-handle already exposes it as
  RawWindowHandle::OhosNdk, and the GLES backend already consumes it.
• OpenHarmony no longer picks up the X11/Wayland extensions. It is unix and reports
  target_os = "linux", but has neither.

ash has no OpenHarmony bindings, so this resolves vkCreateSurfaceOHOS through
get_instance_proc_addr and declares VkSurfaceCreateInfoOHOS locally, copied from
the OpenHarmony SDK's vulkan_ohos.h. Same situation as the existing
Entry::load_from("libvulkan.so") call on ohos. Once ash ships bindings, both can
go away.

Testing

Nothing automated. CI has no OpenHarmony runner, and creating a surface needs a real
XComponent, so none of the existing test suites can reach this path.

I tested it by hand on a HUAWEI MatePad Air (Maleoon 920, HarmonyOS 6.1), running a
renderer that uses storage buffers and compute. Before the patch, Vulkan surface
creation fails, the adapter comes back as backend: Gl (OpenGL ES 3.2), and any
bind group layout with a storage buffer in the vertex stage dies with
DownlevelFlags(VERTEX_STORAGE) are required but not supported. After it, the Vulkan
adapter gets picked and those pipelines build and render.

I have not tried the ohos emulator or any non-Huawei OpenHarmony device.

Squash or Rebase?

Single commit, ready to rebase onto trunk as it stands.

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
  (Only on OpenHarmony, where Vulkan becomes usable instead of GLES-only.)
• Validation and feature gates are in place to confine behavioral changes.
  (All of it sits behind cfg(target_env = "ohos"). Extension availability is
  checked at runtime and reported as a normal InstanceError.)
• Tests demonstrate the validation and altered logic works.
  Not done, for the reasons under Testing. If there is a pattern for covering
  platform WSI code that I have missed, I am happy to add it.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ErichDonGubler]

Hey there! Welcome to wgpu! ❤️

This basically LGTM. I had some feedback that I wanted to be addressed before merging. I took the liberty of pushing my opinions on how to fix things as FIXUP commits on top of what you changed, and will plan on squashing them down on merge if everything looks good to you. WDYT?

[ozongzi]

Thanks for the review and for pushing the FIXUPs! The SAFETY comments and doc links look good to me.