fix #387: window resize never recreated the Vulkan swapchain (stretch)

User report: resolution picks (and window drags) stretched the image
instead of changing the pixel count. Root cause: Campaign V slice V11
deleted the GL viewport target and left a null target, assuming the
driver's OUT_OF_DATE/SUBOPTIMAL acquire/present results would drive
swapchain recreation on resize. That is driver-dependent and
spec-insufficient — this machine's Windows AMD driver keeps presenting
the stale-extent swapchain scaled to the new window indefinitely, so
OnFramebufferResize only ever updated the camera aspect while every
pass (UI included) kept rendering at the old extent.

Fix: SwapchainRecreateViewportTarget implements the existing
IFramebufferViewportTarget seam for Vulkan and arms
VulkanGraphicsContext.RequestRecreate() on every resize event; the next
PrepareFrame rebuilds the swapchain at the live FramebufferSize (bursts
collapse to one recreation, stale events cannot install a stale extent,
minimised sizes stay gated by FramebufferResizeController).

Tests: SwapchainRecreateViewportTargetTests (target contract, size-
agnostic arming, null hook, controller-to-target end-to-end with the
minimised gate). Full Debug App suite 4,941/3 skips.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ISSUES.md

@@ -24,6 +24,38 @@ What does NOT go here:
 - Every session: scan OPEN issues at start; promote/close anything we touched during the session before ending.
 - Promoting to a Phase: mark as `DONE (promoted to Phase X)` + commit SHA where the Phase entry landed.
 
+## #387 — Window resize never recreates the Vulkan swapchain: resolution picks stretch the image instead of changing the pixel count
+
+**Status:** DONE 2026-08-13 (this commit) — pending the user's re-check.
+User report (verbatim shape): "It looks like it is doing now is just
+stretching the window, not changing the pixel count when I change the
+resolution." Confirmed real and root-caused the same session.
+
+**ROOT CAUSE — the resize event never reached the swapchain.** Campaign V
+slice V11 deleted the GL `SilkFramebufferViewportTarget` and left
+`NullFramebufferViewportTarget` on the assumption that the driver's
+OUT_OF_DATE/SUBOPTIMAL acquire/present results would drive
+`VulkanGraphicsContext`'s frame-boundary swapchain recreation whenever the
+window resized. That assumption is driver-dependent and spec-insufficient:
+a conformant driver may keep presenting the stale-extent swapchain scaled
+to the new window indefinitely — which is exactly what this machine's
+Windows AMD driver does. Result: `OnFramebufferResize` updated only the
+camera aspect; the swapchain (and every render pass sized from its extent,
+UI included) stayed at the old pixel count and the presentation engine
+stretched it — for Options resolution picks AND manual window-edge drags
+alike. **Fix:** `SwapchainRecreateViewportTarget` (the Vulkan
+implementation of the existing `IFramebufferViewportTarget` seam) arms
+`VulkanGraphicsContext.RequestRecreate()` on every resize event; the next
+`PrepareFrame` rebuilds the swapchain at the live `FramebufferSize`, so
+event bursts collapse into one recreation and stale events cannot install
+a stale extent. Regressed by
+`tests/AcDream.App.Tests/Composition/SwapchainRecreateViewportTargetTests.cs`
+(target contract + the controller→target end-to-end seam with the
+minimised-gate case). **Re-check:** pick a smaller Resolution — the window
+should shrink AND the image should re-render crisp at the new pixel count
+(UI elements occupy proportionally more of the window, retail-style), not
+scale down blurrily; same for a window-edge drag.
+
 ## #386 — Vendor category dropdown: authored ListBox is edge-docked — retail would size the popup to content, our shipped 6-row window may diverge
 
 **Status:** OPEN — filed 2026-08-13 while fixing #385. The #385 probe