On macOS/Linux a running Chrome lets `Cookies` back up but holds `Login Data`,
`Login Data For Account` and `Web Data` with a hot write lock, so their SQLite
online backup misses the five-second deadline. The launch failed closed with a
bare "3 database(s) unavailable" count, and the docs still promised that macOS
and Linux "can copy the profile while the browser is running" (#111647).
- `_copy_auth_file` returns the failure reason (None on success) instead of a
bool; the backup deadline is the named constant `_AUTH_BACKUP_DEADLINE_S` and
raises `_AUTH_DB_LOCKED`, so the caller can tell "browser holds a write lock"
from "file is not a database".
- `_mirror_profile_auth` returns `{db name: reason}`; the new
`_unavailable_auth_dbs_error` renders "chrome is running and holds the
profile's Login Data, Login Data For Account, Web Data with a write lock …
Fully quit chrome and retry" when every failure is the deadline, and the
per-database SQLite error otherwise. No raw-copy fallback is added: the
no-fallback stance from 58d6d5223a (WAL consistency) is unchanged.
- Docs: the Real-profile note no longer says macOS/Linux copy live; it states
which databases need the browser quit and what the error looks like. The
`real_profile_autoclose` comment stops claiming copy-while-running works on
POSIX.
864e9dccfc