[P1][security] `init_keyring()` panic on Linux + `ConnectionStore::new` `.expect()` block all app launches

[EVWorth]

Context

If the OS keyring backend cannot initialize (no D-Bus Secret Service in a headless/CI/Flatpak session), the app currently panics inside init_keyring() and cannot start.

Problem

src-tauri/src/lib.rs:18-37 calls .expect() on each keyring backend. On Linux, linux_keyutils_keyring_store::Store::new() returns Err when D-Bus Secret Service is unavailable. ConnectionStore::new propagates errors via .expect("Failed to initialize connection store") if migrate_plaintext_passwords fails. Result: any user with existing profiles whose keyring is broken cannot start the app.

Files

• src-tauri/src/lib.rs:18-37, 125
• src-tauri/crates/mas-core/src/connection/store.rs:17-24, 304-329
• src-tauri/crates/mas-core/src/connection/manager.rs (no degraded-mode path)

Repro

Run SQLPilot under dbus-launch --exit-with-session /bin/false (no Secret Service). App crashes on startup before reaching the connection list.

Expected

App starts normally with a status bar banner "Credentials will not be saved across sessions". Profile creation succeeds (in-memory password only). Subsequent launches prompt for password entry until keyring is fixed.

Proposed fix

Scope M. Replace .expect() with explicit error logging + store init error in AppState. Add keyring_status Tauri command returning {available: bool, reason: Option<String>}. In ConnectionStore::new, let _ = migrate_plaintext_passwords(...); when unavailable. Frontend renders banner when available=false.

Acceptance

Launch with no keyring backend available — app starts; banner shown; profile creation succeeds; restart prompts for password.

Needs human verify

Yes.