e2e: scenarios overwrite the real clipboard, and some never restore an image #183

Found 2026-10-11 while tracing the owner's "paste is completely broken" report (a screenshot pasted as file paths; that one came from Prism's e2e, Maxaubert/Prism#356). Prism Terminal's own e2e has the same kind of side effect.

What the e2e does to the real clipboard (confirmed from tools/e2e/run.mjs)

These scenarios write to the Windows clipboard the owner is using while the suite runs:

• caretHold, selectionEdit, pathLinks, reviewKeys: Ctrl+C or clipboard.writeText(...), then put back only the TEXT they read first. An image (a screenshot), HTML, RTF or a file list on the clipboard is lost.
• paste, termClipboard (and the others with the clipboard.write(data) restore): save and restore text, html, rtf and image, which is better, but still not file lists (CF_HDROP), and the clipboard holds test strings (PASTEONCEA, HELD-52, ...) for the length of the scenario.

So during npm run e2e anything the owner copies or snips can be replaced, and after it an image can be gone. This breaks the standing rule that test runs have no side effects outside the app.

Fix direction

• Under --e2e, route the app's clipboard through a stub in main (an in-memory clipboard recorded on a global, as opened links are), so no scenario touches the system clipboard. The scenarios then read and write the stub.
• Where a scenario must use the real clipboard (to prove the OS paste path), save and restore every format, and keep the window short.
• A run-level check: the system clipboard (text and image hash) is the same before and after the suite.