fix(agc): order reused depth layers after queued labels

[p3n1cillin]

An unchanged sampled depth-array layer could be reused while the same queue had an earlier label write over its guest memory that had been decoded but not recorded yet. Such a label is absent from the recorded-write snapshot. The cache hit bypassed ReadCommitted and its flush hook, leaving the label queued and serving stale depth pixels.

Adds a range query over the calling worker's existing queued-label ranges. Depth-layer reuse is refused when that query overlaps the layer; the original checked read then records the queued group through the existing flush hook. Labels outside the layer do not invalidate it. No changes to shader instruction semantics, CPU/GPU write tracking or label ordering rules.

Validation on Windows, GCC 15.2, RTX 5070 / NVIDIA driver 617.42:

• Native regression failed on parent e105fc2 with "the reused depth layer bypassed its preceding queued label write".
• After the guard, the callback lands the queued write before upload; native Vulkan image readback confirms exactly one guest-layer texel changes from 0.75 to 0.5 and every other pixel in both layers is preserved.
• A queued label immediately after the guest layer leaves the cache hit intact and does not invoke the callback.
• Native depth controls: two passed, 0.64 s. Existing protected-mapping, deferred storage write, failed-recording, resident/guest transition, buffer-pool and upload-accounting controls preserved.
• Direct recorder completion-label ordering suite passed with --completion-labels-only.

Full Release build passed. Full CTest: 715 passed, five skipped, zero failures (720 registered), 57.76 s.

ASTRO BOT PPSA21564 v01.007.000, exact head 66ea007, Windows / RTX 5070 / driver 617.42, 16 GiB host-import limit, profiling enabled and compiler/pipeline caches preserved. The user manually advanced the title into intro_next and reported frozen cinematic footage while loading.

The capture contains an 83.641 s gap before completed frame 2312. In that interval, five Vulkan.Dispatch.pipeline_create phases total 69.392 s (maximum 17.746 s each), versus 23.824 ms across recorder Sync phases. Another worker records 70.530 s in memory-wait phases. Source inspection confirms compute pipeline creation runs inside the dispatch GPU mutex; its timing phase also includes layout/module cleanup and pipeline statistics, so it is not an exclusive driver-call measurement. The log reports large compute shaders, including 677,121-809,411 SPIR-V words.

Frames resume after the gap and reach 2329 before the diagnostic monitor intentionally stops the game at six minutes. This establishes a severe loading/pipeline-creation stall, not a confirmed permanent deadlock. Available physical memory briefly falls to 54.996 MiB; sampled working set peaks at 24,925.117 MiB. Memory pressure may aggravate compilation/loading, but causality has not been isolated. Shader cache reports 1,831 hits and 52 misses/writes. No fatal abort, device loss, BDA fault or presentation-failure report was found.

Manual input changed the workload, so this run is not a controlled title-screen performance comparison. Overall completed-flip rate is 7.205/s, p95 162.977 ms, with the long loading gap included. Diagonal banding remains in captured frames. Correct cinematic rendering, gameplay, audio, saves and 60 FPS remain unverified. All game and helper processes are terminal; no subsequent game run was started at the user's request.

Next investigation: compute-pipeline creation cost, large generated SPIR-V and physical-memory pressure during intro_next loading. Latest upstream de5e541 was fetched and its integration conflicts previewed, but it has not been merged or built.

Depends on #22. Draft follow-up in the personal fork, based on the ASTRO BOT integration stack rather than upstream main. AI-assisted. Private game assets and diagnostic dumps are excluded from source control and public records.