Stabilize Notion manual-demo recorder window targeting

[schickling-assistant]

Problem

The new chaptered manual-demo workflow for @overeng/notion-react can now generate source states, sync them into the canonical Notion page, and validate the result through tmux proof plus direct Notion API reads.

The remaining gap is the visual recorder's window targeting:

• Ghostty and Chrome window discovery is still heuristic
• if the dedicated Chrome window's front tab drifts away from the manual demo page, browser-window screenshots and recordings can capture the wrong surface
• the validator can still prove correctness through the API, but the resulting visual artifact no longer matches the intended storyline

Desired outcome

Make the visual recorder deterministic enough that the same script can always capture the intended Ghostty + dedicated Chrome manual-demo pair without relying on fragile title matching.

Candidate approaches

• assign explicit stable identifiers to the dedicated demo windows and resolve them without title heuristics
• keep the dedicated automation browser isolated to a single manual-demo tab/window
• add a preflight assertion that the captured browser surface contains an expected chapter string before recording continues
• consider a CDP-backed browser capture path so the browser proof does not depend on the front tab title at all

Acceptance criteria

• scripts/manual-video/record-full-demo.sh fails fast when the browser target is wrong
• validator/browser proof can distinguish the intended manual-demo window from unrelated Chrome tabs
• full demo recording can be rerun repeatedly without manual window retargeting between takes