docs(70): queue the Live Window App overlay layer

Record the creator's Live-only, single-layer scope and distinguish it from the
existing session-scoped Capture Window backdrop pin. Include HWND lifecycle,
protected-window, visual-only, and duplicate-underlay boundaries.

Reference scan: Microsoft HWND capture item API and OBS Window Capture:
https://learn.microsoft.com/en-us/windows/win32/api/windows.graphics.capture.interop/nf-windows-graphics-capture-interop-igraphicscaptureiteminterop-createforwindow
https://obsproject.com/kb/window-capture-sources

HANDOFF.md

@@ -2,7 +2,7 @@
 
 ## State
 
-- `main`, worktree clean. App work is pushed through `b265d42`; TASK 69 queue update is local only.
+- `main`. App code is pushed through `b265d42`; queue-only docs commits are local.
 - **Done:** TASK 35 scene-linked audio, TASK 55 disk hygiene, TASK 65 replay clips, TASK 37 defaults/current split.
 - TASK 37: SQLite keeps an immutable default snapshot beside build-stamped current rows; App Settings can
   restore the staged scene or all scenes, offline only. Webcam identity survives both restore paths.
@@ -12,7 +12,7 @@
 
 ## Next action
 
-- Queue: **40·A/C/D → Move → 9·5 → 14·16/17/18 → 66 → 67 → 68 → 69 → 36**.
+- Queue: **40·A/C/D → Move → 9·5 → 14·16/17/18 → 66 → 67 → 68 → 69 → 70 → 36**.
 - Ask creator before TASK 68 about first-run ON-AIR default; before gold pass, settle the Release
   single-instance mutex behavior.
 - TASK 34 scheduling and TASK 50 recording publish are retired; YouTube owns those surfaces.

TASKS.md

@@ -9,7 +9,7 @@
 
 **Creator ruling 2026-11-09 — finish the queue before the new features, gold pass always last.**
 
-`40·A/C/D → Move → 9·5 → 14 (remaining slices) → 66 → 67 → 68 → 69 → 36`
+`40·A/C/D → Move → 9·5 → 14 (remaining slices) → 66 → 67 → 68 → 69 → 70 → 36`
 
 The rule behind the two retirements below: **do not rebuild the platform's own surface.** Scheduling,
 publishing, moderation and channel management are YouTube's; the app owns capture → scene → sound →
@@ -31,6 +31,7 @@ output.
 | 67 | ☐ | **Per-event alert videos** — a clip per monetization event, falling back to the default | [`task-67`](TASKS/task-67-per-event-alert-videos.md) |
 | 68 | ☐ | **Editing while live** + first-run On-Air state matching the 1-2-3 screen | [`task-68`](TASKS/task-68-edit-while-live.md) |
 | 69 | ☐ | **Chat sample-preview toggle** — per-layer control to show/hide mock chat in the preview; real messages unaffected, never output | [`task-69`](TASKS/task-69-chat-preview-toggle.md) |
+| 70 | ☐ | **Window App layer** — capture one selected running app window as a visual layer over Live's game/display capture | [`task-70`](TASKS/task-70-window-app-layer.md) |
 | 36 | ☐ | **Gold pass** — the v1 gate: screens/layers audit (every control does something), native-Windows verification, branding-flash decision. Always the last unit | [`task-36`](TASKS/task-36-gold-pass.md) |
 | 34 | ❌ | **Scheduled streams — retired 2026-11-09.** YouTube owns scheduling *and* the reminder that makes it useful; the app neither creates nor displays scheduled broadcasts, and there is no value in a copy that can fall out of sync | [`decisions`](docs/ai/decisions.md) |
 | 50 | ❌ | **Publish recording — retired 2026-11-09.** YouTube Studio owns upload (resumable, quota-aware, and it explains rejections). In-app publishing would also widen the OAuth consent to whole-channel video management. The recording lands in the creator's folder; the app adds "Show in folder" instead | [`decisions`](docs/ai/decisions.md) |

TASKS/task-70-window-app-layer.md

@@ -0,0 +1,45 @@
+# TASK 70 — Window App layer
+
+**Status:** ☐ Queued (creator request 2026-11-11); scheduled after TASK 69 and before the gold pass.
+
+## Request and locked limits
+
+Add a **Window App** layer that captures a specific running app window and composites it above the
+Live scene's game/display Background. Example: show a terminal over a game. This is an ordinary
+foreground visual layer, not the existing TASK 38 **Capture Window…** action, which replaces the
+locked Background itself.
+
+- Available in **Live only**.
+- At most **one Window App layer** may be active in the layout.
+- It cannot remove or mask the target from the underlying game/display capture. If the app is already
+  visible in those captured pixels, it may appear twice; do not select the game/already-captured app as
+  the overlay target.
+- Visual only; no independent per-app audio capture or routing.
+- Enumerate visible top-level windows of other processes. A process with several windows may offer
+  several titled entries; this selects a window, not every window owned by the process.
+
+## Capture boundaries
+
+- Target HWNDs are session-scoped. Never resurrect a raw HWND after restart: Windows can recycle it to
+  an unrelated window. The creator must select the window again for a new session.
+- If the target closes, minimizes, suspends rendering, or cannot be captured, its image may freeze,
+  disappear, or go black; release the dead capture rather than leaving an apparently live layer.
+- Secure/protected content may be returned black or excluded by Windows. This is an OS restriction,
+  not something LlamaCasty can bypass.
+
+## Acceptance
+
+- Add → Window App lists eligible windows and selection adds one Live-scene layer above the Background.
+- The source updates while its target window is running, independent of whether another window covers it.
+- The app refuses a second Window App layer and refuses adding this source outside Live.
+- Target closure/failure is surfaced and releases the capture; restarting never reuses a saved HWND.
+- One Good Dog integration test drives a fake capture source/enumerator. A real Windows visual check is
+  required before commit.
+
+## Reference scan
+
+- Windows Graphics Capture exposes HWND-targeted items via
+  [`IGraphicsCaptureItemInterop::CreateForWindow`](https://learn.microsoft.com/en-us/windows/win32/api/windows.graphics.capture.interop/nf-windows.graphics.capture.interop-igraphicscaptureiteminterop-createforwindow).
+- OBS's [Window Capture source](https://obsproject.com/kb/window-capture-sources) confirms the intended
+  foreground-source behavior; Windows documents that protected windows may be black or omitted in
+  [New Ways to do Screen Capture](https://blogs.windows.com/windowsdeveloper/2019/09/16/new-ways-to-do-screen-capture/).