windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m9s
ci / bun-nix (pull_request) Successful in 30s
ci / web (pull_request) Successful in 1m20s
apple / swift (pull_request) Successful in 1m28s
apple / screenshots (pull_request) Skipped
ci / docs-site (pull_request) Successful in 1m51s
ci / rust-arm64 (pull_request) Successful in 2m44s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m46s
android / android (pull_request) Successful in 4m16s
ci / rust (pull_request) Successful in 4m52s
Nothing in the caps module logged anything, so when a device refused with "advertises neither DPB_AND_OUTPUT_COINCIDE nor DISTINCT" there was no way to separate two very different situations that present identically as a zero: the driver filling the chain and genuinely declaring no DPB mode, versus our own pNext chain never reaching VkVideoDecodeCapabilitiesKHR at all. Printing the BASE VkVideoCapabilitiesKHR beside the decode flags is the discriminator. A populated max_dpb_slots next to decode_flags: 0 means the driver traversed the chain and answered; zeros across both mean the query never landed and the refusal is ours, not the driver's. Raised by the Intel Arc result on .221, where I concluded "driver bug" on the strength of our own code's report — which is precisely the circular reasoning this line exists to break.