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/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.