fix(gui,cli,core): offer the CAPTCHA in the browser when the web view cannot start (B195)

The verification window now runs in its own process, so the app survives
when WebKit cannot start its sandbox on secureblue, but the CAPTCHA still
could not be solved there (#29). WebKit binds the journal socket with
`--ro-bind-try`, bubblewrap only skips a missing path, not an unreadable
one, and WebKit has no switch to leave the socket out.

Proton Mail Bridge never uses a web view: it opens verify.proton.me in the
system browser and retries with the original challenge token, typed with
the offered methods. Do the same as a fallback.

- core: `browser_verification_url` and `browser_verified` build the page
  URL and the retry credential from the challenge
- gui: when the verification window fails, a dialog opens the page in the
  browser and continues the sign-in once the user is done
- cli: `pdfs login` handles a CAPTCHA the same way instead of failing
- i18n: translate the new dialog in every catalog
- docs: B195, TROUBLESHOOTING.md, ARCHITECTURE.md, changelog

Fixes #29

docs/ARCHITECTURE.md

@@ -563,9 +563,13 @@ sequenceDiagram
 - The page may post the token as an object or as a JSON string; both are accepted.
 - The page runs in a WebKitGTK view inside a child `pdfs-app`. WebKit aborts its process when its
   sandbox cannot start, as on hardened systems such as secureblue (B195). In the child, that ends
-  the verification, and the app says why, instead of closing the app.
-- The CLI has no web view. It fails with a message to sign in once with `pdfs-app`; the stored
-  session then works for the CLI and the service.
+  the web view, not the app.
+- When the child fails, the app offers the page in the user's own browser instead, as Proton Mail
+  Bridge does. A browser tab cannot post the token back, so the user says when they are done, and
+  the retry carries the challenge token itself, which the solved page made good. Its type header
+  lists every offered method (`auth::browser_verified`).
+- The CLI has no web view, so it always takes the browser path: it prints the page's URL and waits
+  for Enter.
 
 ---
 

docs/BUGS.md

@@ -300,29 +300,38 @@ Newest first.
 
 ### B195 — The app crashes when Proton asks for a CAPTCHA on secureblue
 
-**Status:** Fixed (unverified). Nobody has run the fix on secureblue yet.
+**Status:** Fixed (unverified). On 2026-10-08 the reporter confirmed that the app survives, but
+the CAPTCHA still could not be solved; the browser fallback below has not run on secureblue yet.
 **Found:** 2026-10-07, [#29](https://github.com/narrrl/proton-drive-linux/issues/29). On
 secureblue 44 (a hardened Fedora Atomic), `pdfs-app` aborted a few seconds after the sign-in, with
 `bwrap: Can't get type of source /run/systemd/journal/socket: Permission denied` and
 `Failed to fully launch dbus-proxy`.
-**Where:** `crates/pdfs-gui/src/app/pages/verify.rs`, `crates/pdfs-gui/src/app/pages/login.rs`
+**Where:** `crates/pdfs-gui/src/app/pages/verify.rs`, `crates/pdfs-gui/src/app/pages/login.rs`,
+`crates/pdfs-core/src/auth.rs`, `crates/pdfs-cli/src/main.rs`
 
 **Repro:** Sign in on secureblue from a network Proton asks a CAPTCHA for, such as a VPN.
 
 **Cause.** The CAPTCHA page runs in a WebKitGTK view (B8). Before it loads anything, WebKit starts
 its sandbox: bubblewrap, with the journal socket bound in, and `xdg-dbus-proxy`. secureblue keeps
 bubblewrap from the socket, the proxy does not start, and WebKit ends its process with `g_error`.
+WebKit binds the socket with `--ro-bind-try`, but bubblewrap skips only a missing path, not one it
+may not read, and WebKit has no switch to leave the socket out.
 The view was in the app's own process, so the whole app went down, and nothing in our code can
 catch that.
 
 **Fix.** The view runs in a child, `pdfs-app --human-verification`, that reads the URL on stdin
 and prints the token on stdout. A child that exits without a token after a crash or a non-zero
-status ends the sign-in with a message that says the page could not be opened. TROUBLESHOOTING.md
-gives the cause and a one-time workaround. The sandbox is not switched off by the app: users choose
-a hardened system for that isolation.
+status no longer ends the sign-in: the app offers the page in the user's own browser, as Proton
+Mail Bridge does. The tab cannot post the token back, so the user says when they are done, and the
+retry carries the challenge token, typed with every offered method. `pdfs login` takes the same
+path. The sandbox is not switched off by the app: users choose a hardened system for that
+isolation. TROUBLESHOOTING.md keeps the one-time workaround as a last resort.
 
 **Test:** unit tests `a_window_that_died_fails`, `a_window_closed_without_a_token_cancels`,
-`a_token_counts_even_if_the_window_died_after_it` and `the_token_is_found_among_other_output`.
+`a_token_counts_even_if_the_window_died_after_it`, `the_token_is_found_among_other_output`,
+`the_browser_gets_the_full_verification_page` and
+`a_browser_verification_retries_with_the_challenge_token`. The browser retry has not run against a
+live challenge: Proton only asks for one from a network it distrusts.
 On 2026-10-08 the child ran under real WebKit on Arch against a local page that posts a completion,
 and handed back its token.
 

docs/CHANGELOG.md

@@ -11,6 +11,12 @@ scratch (user data in `staging/` and `recovery/` is never touched by this).
 
 ## [Unreleased]
 
+### Fixed
+- **A CAPTCHA could not be solved on hardened systems.** When the verification page cannot open in
+  the app, as on secureblue, the app now offers it in your browser and continues the sign-in
+  once you are done. `pdfs login` now handles a CAPTCHA the same way instead of failing.
+  ([#29](https://github.com/narrrl/proton-drive-linux/issues/29))
+
 ## [3.1.2] — 2026-10-08
 
 Schema: **42**, unchanged.

docs/TROUBLESHOOTING.md

@@ -69,14 +69,16 @@ pdfs status
 ## Signing in
 
 **"Proton is asking for a CAPTCHA"** — Proton wants human verification, usually on a VPN or an
-unfamiliar network. The CLI cannot show it. Sign in with `pdfs-app`, which displays the challenge;
-the stored session then works for the CLI too.
+unfamiliar network. `pdfs login` prints the verification page's address: open it in your browser,
+complete it, then press Enter. The app shows the page in its own window.
 
-**"The verification page couldn't be opened"** — WebKit, which shows the CAPTCHA page, could not
-start its sandbox. Hardened systems such as secureblue keep its bubblewrap from the journal socket,
-and the log then shows `bwrap: Can't get type of source /run/systemd/journal/socket: Permission
-denied` and `Failed to fully launch dbus-proxy`. Check that `bwrap` and `xdg-dbus-proxy` are
-installed. If they are, sign in once with the sandbox switched off for this one run:
+**"Verify in Your Browser"** — WebKit, which shows the CAPTCHA page in the app, could not start
+its sandbox. Hardened systems such as secureblue keep its bubblewrap from the journal socket, and
+the log then shows `bwrap: Can't get type of source /run/systemd/journal/socket: Permission
+denied` and `Failed to fully launch dbus-proxy`. Choose **Open Verification Page**, complete the
+page in your browser, then choose **Continue**. If that sign-in is refused too, check that `bwrap`
+and `xdg-dbus-proxy` are installed. As a last resort, sign in once with the sandbox switched off
+for this one run:
 
 ```bash
 WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 pdfs-app