docs: file #388 — fullscreen-state video-mode crash + silent resolution-pick no-op (user gate session evidence)

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

docs/ISSUES.md

@@ -24,6 +24,43 @@ 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.
 
+## #388 — CRASH: unhandled GlfwException "Failed to set video mode: Graphics mode not supported" during a fullscreen-state resolution/settings apply; and fullscreen/maximized windows silently ignore resolution picks
+
+**Status:** OPEN — filed 2026-08-13 from the user's live gate session
+(log: scratchpad `rdp-verify.log` / task b7rd8zkd4, exit 29 after an
+unhandled `Silk.NET.GLFW.GlfwException`). Two distinct facts from the
+same session, both in the #376/#377 fullscreen family:
+
+1. **The crash.** With the persisted display state carrying
+   `fullscreen: true`, a settings apply attempted a GLFW video-mode
+   change ("Failed to set video mode: Graphics mode not supported").
+   The first failure surfaced as `settings: display save failed:
+   PlatformError...` (caught), then a second fired as an UNHANDLED
+   exception from GLFW's error callback and killed the process
+   mid-session. Likely path: `SilkRuntimeDisplayWindowTarget.Apply`
+   writing `_window.Size`/`WindowState` while the window is in Silk
+   fullscreen — GLFW size writes on a fullscreen window are video-mode
+   requests, and an unsupported mode (816x639 was in flight) is fatal
+   through Silk's throwing error callback. Root-cause exactly before
+   fixing; the crash also re-saved `fullscreen: true`, arming the #377
+   startup crash on the NEXT launch (recovered by hand-editing
+   settings.json back to false, the documented #377 recovery).
+2. **The silent no-op.** Earlier in the same log, five consecutive
+   resolution picks (2560x1440 / 3840x2160 / 1366x768 / 800x600 x2, all
+   "window was 2056x1290") produced NO framebuffer-resize event and NO
+   swapchain recreation — the Size writes were silently ignored by the
+   window state the client was in (fullscreen/maximized family). This is
+   the concrete mechanism behind the user's "the resolution does not
+   change" report in that state. In plain windowed state the same
+   session's own picks DID work end-to-end (`pick 800x600 → event
+   800x600 → swapchain recreated 800x600 ok=True`, #387's chain).
+
+Both fold into the promoted fullscreen work block (#376 native
+glfwSetWindowMonitor + mode-list validation, #377 startup crash): the
+Apply path must become state-aware — windowed pick = window resize
+(shipped, #387); fullscreen pick = validated native mode switch; never
+a raw Size write against a fullscreen window.
+
 ## #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.