feat(example): VK weave scope, device-side pack guidance, runtime pin → v2.12.0

[dfattal]

Follow-up to #4, which covered the D3D11 stub only. Auditing the template as a vendor would actually read it turned up three gaps.

1. The VK DP had no get_scanout_caps

A Vulkan-first vendor (or anyone shipping Linux) got no example and, worse, no signal that declaring scope is mandatory for them too.

Added — with the pointer-type trap called out explicitly, because it is genuinely easy to get wrong: every other method in example_processor_vk.c takes the generic base (struct xrt_display_processor *), but this slot is on the VK variant (struct xrt_display_processor_vk *) and registers on dp->base, not dp->base.base. The reason is worth knowing rather than memorising: the variant embeds the base by value, so the scope query could not be added to the base without shifting every appended variant slot (ADR-020).

2. example_device.c never mentioned hardware weaving — but it's the file that decides the pack

This is the conceptual link the template was missing. For a hardware-weaving display the device file matters more than the weaver: the tile geometry declared there is the layout the chip receives, which is exactly why process_atlas can be a passthrough. Nothing in the template said so.

Documented inline: the three common packs (SBS-half 2×1 @ 0.5,1.0, top-and-bottom 1×2 @ 1.0,0.5, quilt N×M), the XRT_MAX_VIEWS = 8 ceiling and why exceeding it is a runtime ABI change rather than a plug-in one, and why the template's existing 1×1 @ 1.0,1.0 + 2×1 @ 0.5,1.0 pair is worth keeping even for an SBS-only product — it's the only shape making both modes fill the worst-case swapchain envelope, which is the sole condition for zero-copy (ADR-030). A 0.5 × 0.5 3D mode always costs a copy.

3. The pin predated the slot, so #4 was inert

DXR_RUNTIME_GIT_TAG was v2.7.1 — older than the runtime change — so every #ifdef XRT_DP_*_HAS_SCANOUT_CAPS block added in #4 compiled out. A fresh fork saw code that did nothing.

Bumped both coupled pins (CMakeLists.txt + workflow RUNTIME_REF, which the Rule-5 drift check hard-fails if they diverge) to v2.12.0, the first release carrying the slot.

Checked before bumping, rather than assuming a 5-minor jump was free:

• both tags report XRT_PLUGIN_API_VERSION_CURRENT = 5, so it's ABI-compatible;
• the vcpkg commit this template pins is byte-identical between v2.7.1 and v2.12.0, so the "keep vcpkg in sync with the runtime's CI" coupling doesn't move;
• the Vulkan SDK pin is independent of the runtime tag (the runtime dropped the LunarG step; this template still uses it), so it stays put.

Verification

All three stubs syntax-check clean against v2.12.0 headers with the guards ON (cl /Zs): example_processor_d3d11.cpp, example_processor_vk.c, example_device.c. CI here is the real test of the pin bump — it builds the full plug-in + installer against v2.12.0 via FetchContent.