Record AppVM startup success after memory tuning

Setup.md

@@ -123,7 +123,7 @@ Thread-safety expectation:
   - missing: `mvp`, `setup`, `components`, `samples`
 - `CR_SDK_CK-main/scripts/build_flash_mvp.sh` exists, but it expects the above role directories.
 - Python helper scripts were intentionally moved out of `CR_SDK_CK-main/scripts` and are now maintained at workspace root.
-- Qubes VM provisioning is currently blocked: `libxenlight` failed to create domain `k_client`.
+- Qubes AppVM baseline is now up: `k_client`, `k_proxy`, `k_server` can start and have terminals running.
 
 Implication:
 - We cannot currently confirm live FIDO2 connectivity from this host.
@@ -133,6 +133,7 @@ Session note (2026-04-24):
 - Markdown tracking was reviewed and normalized around `Setup.md` + `Workplan.md` as the active, continuously updated execution record.
 - AppVM template decision recorded: use `debian-13-xfce` for `k_client`, `k_proxy`, and `k_server`.
 - VM start attempt failed with Xen toolstack error: `libxenlight have failed to create new domain 'k_client'`.
+- VM start blocker was resolved by reducing VM memory to `400` MiB; all three AppVMs now start.
 
 ## Known FIDO2 Transport Boundary
 
@@ -187,7 +188,6 @@ SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="0005", MODE="06
 
 ## Open Gaps To Resolve
 
-- Why Xen/libxenlight cannot create the `k_client` domain on this host (memory/pool, stale domain, template, storage, or hypervisor state).
 - Why no `/dev/hidraw*` device is visible despite USB connection.
 - Whether udev rule is missing or device VID/PID differs from expected.
 - Whether current firmware on card exposes the FIDO2 HID interface.