fix(client): a film can go full-screen, and automatic saving is automatic

**Full-screen was denied, and the denial was invisible.** The permission
handler was written from a true sentence — nothing here needs a camera, a
microphone or a location — and implemented as `callback(false)` for everything.
Chromium's own video controls ask for the `fullscreen` permission, so a film
could not be watched full-screen.

What made it hard to find, and what the test now pins: **a denied `fullscreen`
does not reject.** `requestFullscreen()` returns a promise that never settles.
No exception, no console message, nothing in the renderer that mentions a
permission — the button just does nothing. Measured rather than reasoned: the
probe reported `NEVER SETTLED` while the main process, instrumented for one run,
logged `PERMISSION ASKED: fullscreen`. After the fix the same probe reports
`granted` with `document.fullscreenElement` set.

The handler now enumerates what is *granted* — `fullscreen`, and nothing else —
so a camera, a microphone, a location, notifications and MIDI are still refused
and whatever Chromium adds next arrives refused rather than quietly allowed.
`Permissions.query` takes the other handler, so both now answer from the one
list instead of eventually disagreeing.

The old test asserted `callback(false)`, which is to say it locked in the bug.
It is replaced by three: what must stay denied, that `fullscreen` is granted,
and that both handlers read the same list.

**"Save automatically" opened a dialog.** The automatic path required a folder
to have been chosen first, and on a new profile nobody has chosen one — so the
very first download fell through to Save As, which is the one thing the setting
promises not to do. A browser does not make you pick a folder before it will
save a file; the system Downloads folder is the answer when there is no other.
Verified on a fresh profile with a home of its own: no dialog, 1024 bytes on
disk, destination reported as the default (`/home/…/Téléchargements` on this
machine, via the localized XDG directory).

A folder that *was* chosen and has since gone still asks. Silently redirecting
those files is worse than a dialog: someone who picked an external drive wants
to be told it is not there, not to find the film in their home directory a week
later. Settings shows the effective destination either way, and offers "forget"
only for a folder somebody actually chose.

813 tests pass.

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

1 files changed, 12 insertions, 1 deletions

diff --git a/docs/desktop-client-v1.md b/docs/desktop-client-v1.md
index 23287dd..c0bbb90 100644
--- a/docs/desktop-client-v1.md
+++ b/docs/desktop-client-v1.md
@@ -181,7 +181,18 @@ Electron it is nearly all of it.
 
 ### 3.1 What running it changed
 
-Three of the statements above were wrong, and only launching the application found them.
+Four of the statements above were wrong, and only launching the application found them.
+
+**"Nothing here needs a camera, a microphone or a location" was true, and the handler
+written from it was still wrong.** Denying every permission also denied `fullscreen`, and
+Chromium's own video controls ask for it — so a film could not be watched full-screen.
+What makes this worth recording rather than just fixing: **a denied `fullscreen` does not
+reject.** `requestFullscreen()` returns a promise that never settles. No error, no console
+message, nothing in the renderer that names a permission; the button simply does nothing,
+and the operator reported it as "impossible to go full-screen" with no lead to follow. The
+probe reported `NEVER SETTLED` while the main process logged `PERMISSION ASKED:
+fullscreen`, which is what tied the two ends together. The handler now enumerates what is
+*granted* — one entry — so anything Chromium adds later still arrives refused.
 
 **The CSP cannot live in a `<meta>` tag.** `frame-ancestors` is ignored there — Chromium
 says so in the console — so a policy carrying it has one directive that silently does