Linux: Cairo + Vulkan Backend for much needed performance improvement

Problem

macOS rasterizes canvas on CPU (Core Graphics / Core Text) then presents via
Metal. Linux has no such split → no GPU present path, no CPU-raster fast path.

Fix

Same two halves on Linux:

• Vulkan presenter (native_sdk_vk.c/.h) — Metal analog. gpu_surface view
  scans out through SDK-owned Vulkan swapchain on a native child surface the
  compositor composites directly: wl_subsurface (Wayland) or child
  InputOutput window (X11). Shaders compiled inline via shaderc (mirrors
  Metal host's inline MSL). No Vulkan surface → falls back .software.
• Cairo/Pango packet renderer (native_sdk_cairo.c, opt-in SCHEMIFY_CAIRO=1)
  Core Graphics + Core Text analog. Immediate-mode 2D, driven command-by-command
  from the canvas packet. Payload-structural dispatch: unpaintable command
  refuses the frame → runtime falls back to reference renderer (correct, just
  unaccelerated).

Both present through the descriptor-pointer GPU seam → correct under self-hosted x86_64.

Notes

• root.zig references Cairo symbols unconditionally → every Linux link
  (framework + each example build.zig) must compile native_sdk_cairo.c +
  link freetype2.
• Verified: zig build test-webview-system-link -Dplatform=linux -Dweb-engine=system
  compiles + links gtk_host.c + native_sdk_vk.c + native_sdk_cairo.c
  against gtk4 / webkitgtk-6.0 / cairo / pango / vulkan / shaderc / wayland / x11.

Start with root.zig and the referenced native_sdk_vk.c/.h and native_sdk_cairo.c files, then inspect the framework and example build.zig files. Run zig build test-webview-system-link -Dplatform=linux -Dweb-engine=system to establish the current link path. Done means the Linux Vulkan and opt-in Cairo paths compile and link with the stated fallback behavior.