nvrl d13e74fc12 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

2026-10-08 19:02:29 +02:00

..

pdfs-cli

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

2026-10-08 19:02:29 +02:00

pdfs-core

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

2026-10-08 19:02:29 +02:00

pdfs-fuse

fix(cli,fuse): keep answering the systemd watchdog while the daemon retries

2026-10-07 08:17:50 +02:00

pdfs-gui

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

2026-10-08 19:02:29 +02:00