Local-only mode already WORKED — verified by driving a genuinely fresh
profile (no credentials, keyring unreachable): "Start offline" enters the
guest profile, Local Library opens with its proper empty state, Settings
renders in full, zero QML complaints. The capability was never the
problem. Two pieces of the screen were.
1. THE SIGNPOST WAS OFF FOR EXACTLY THE RIGHT PERSON. The callout with
the caret pointing at the Start-offline link was gated on
`hasPreviousSession && connectivity === 2`. `hasPreviousSession` is
seeded from `load_last_user_id()` — None on a fresh profile — and only
ever set true by a successful Qobuz login. So the one piece of UI that
says "you can use this without an account" could not be seen by
anybody who had never signed in. The gate was written for the
returning-user-with-no-wifi case and the guest case was bolted onto
the link alone.
2. THE COPY WAS FALSE. Once that box is visible to a first-run user with
working internet, "No internet connection" is simply untrue, and the
offline placeholder said the same thing after entering: measured on a
fresh profile, the log read `connectivity Up, induced false,
offline_session true` while the screen claimed the network was down.
Both now branch on which of the THREE states this is — induced
offline, no connectivity, or no account — and the captive-portal line
is gated on connectivity too, so it cannot appear under a "No Qobuz
account?" heading.
Two new msgids in all seven non-English catalogues.
Verified after the change on a fresh profile: the callout appears, the
link is reachable, and the placeholder reads "You're using QBZ without a
Qobuz account."
HARNESS NOTE for whoever tests this next: XDG_CONFIG_HOME sandboxes the
token FILE but NOT the system keyring, and a rejected token there calls
`clear_oauth_token`, which deletes the keyring entry for the real user.
Point DBUS_SESSION_BUS_ADDRESS at nothing so the Secret Service is
unreachable. (The file stays authoritative, so nothing is lost — but the
run is not clean either.)
cc