Surface the login keyring, and offer to unlock it

The keyring is already unlocked at sign-in exactly as GNOME does it --
pam_gnome_keyring is in GDM's stack and the journal confirms it works
("gnome-keyring-daemon started properly and unlocked keyring"). So there
was no configuration bug to fix. What a bare Hyprland session lacks is
anywhere to see when that has stopped being true.

It stops being true rarely and expensively. gnome-keyring-daemon crashed
once on this machine -- an upstream abort in service_method_open_session,
with a core dump -- and D-Bus then activated a replacement. That
replacement never received the login password, so the keyring was locked
in the middle of a session that had unlocked it correctly at login.
Nothing announces this. What you see instead is a mail account that will
not authenticate, a git push that cannot find its key, or an integration
reporting "not configured", none of which mention keyrings. That is the
same root cause as the Home Assistant token failure earlier.

Privacy & Security now shows the state, offers an Unlock action that
raises the standard password dialog, and reports when the daemon holding
your secrets is a D-Bus replacement rather than PAM's -- because a
replacement that is currently unlocked was unlocked by hand and will not
survive a restart. The password never passes through Panama.

The contract stubs the secret service rather than touching the real one:
locking the login keyring breaks every saved password on the machine and
can only be undone by typing the password into a dialog, so it is not
something a test suite may do to a daily driver. Verified it catches a
helper that misreports locked as unlocked, and one that crashes instead
of reporting a missing service.

Worth recording: a locked keyring makes a NON-INTERACTIVE caller appear
to hang. It is not hung -- it is waiting on a dialog nobody is looking
at, which is exactly how the earlier secret-tool investigation lost an
hour.

Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L

tests/quickshell/keyring-helper-contract.sh

@@ -0,0 +1,108 @@
+#!/usr/bin/env bash
+
+# panama-keyring reports the login keyring's state, and the Settings page reads
+# nothing but its JSON.
+#
+# The state that matters is LOCKED, and it is also the one that cannot be
+# rehearsed on a real desktop: locking the login keyring breaks every saved
+# password on the machine and can only be undone by typing the password into a
+# dialog. So the secret service is stubbed here instead. Nothing touches the
+# real keyring -- this contract is safe to run on the daily driver, which is the
+# entire reason it is written this way.
+
+set -uo pipefail
+
+repo_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)"
+helper="$repo_dir/config/dot/quickshell/scripts/panama-keyring"
+
+fail() {
+    printf 'keyring helper contract: %s\n' "$1" >&2
+    exit 1
+}
+
+stub_dir="$(mktemp -d /tmp/panama-keyring.XXXXXX)"
+trap 'rm -rf "$stub_dir"' EXIT
+
+# A stand-in for the `gi` module the helper imports. PANAMA_KEYRING_FAKE decides
+# what the fake service reports, so one stub covers every case.
+mkdir -p "$stub_dir/gi/repository"
+cat >"$stub_dir/gi/__init__.py" <<'STUB'
+def require_version(*_args, **_kwargs):
+    return None
+STUB
+cat >"$stub_dir/gi/repository/__init__.py" <<'STUB'
+import os
+
+
+class _Collection:
+    def __init__(self, label, locked):
+        self._label = label
+        self._locked = locked
+
+    def get_label(self):
+        return self._label
+
+    def get_locked(self):
+        return self._locked
+
+
+class _Service:
+    def get_collections(self):
+        mode = os.environ.get("PANAMA_KEYRING_FAKE", "unlocked")
+        if mode == "nologin":
+            return [_Collection("Some App", False)]
+        return [_Collection("Login", mode == "locked"), _Collection("", False)]
+
+
+class _ServiceFactory:
+    @staticmethod
+    def get_sync(_flags, _cancellable):
+        if os.environ.get("PANAMA_KEYRING_FAKE") == "unavailable":
+            raise RuntimeError("no secret service")
+        return _Service()
+
+    # unlock_sync is what the `unlock` action calls; record that it was reached.
+    @staticmethod
+    def _noop(*_args, **_kwargs):
+        return None
+
+
+class Secret:
+    class ServiceFlags:
+        LOAD_COLLECTIONS = 1
+
+    Service = _ServiceFactory
+STUB
+
+run() {
+    PYTHONPATH="$stub_dir" PANAMA_KEYRING_FAKE="$1" python3 "$helper" "${2:-status}"
+}
+
+# ── Unlocked: the normal state after any sign-in ─────────────────────────────
+out="$(run unlocked)"
+jq -e . >/dev/null 2>&1 <<<"$out" || fail "status did not emit JSON: $out"
+jq -e '.available == true and .locked == false and .hasLogin == true' >/dev/null <<<"$out" \
+    || fail "an unlocked login keyring was misreported: $out"
+
+# ── Locked: the state the whole card exists for ──────────────────────────────
+out="$(run locked)"
+jq -e '.available == true and .locked == true' >/dev/null <<<"$out" \
+    || fail "a locked login keyring was not reported as locked: $out"
+
+# ── No secret service at all is a state, not a crash ─────────────────────────
+out="$(run unavailable)"
+jq -e . >/dev/null 2>&1 <<<"$out" \
+    || fail "a missing secret service produced no JSON, so the page would show nothing: $out"
+jq -e '.available == false and .error != ""' >/dev/null <<<"$out" \
+    || fail "a missing secret service must be reported with a reason: $out"
+
+# ── No login keyring: not locked, because there is nothing to lock ───────────
+out="$(run nologin)"
+jq -e '.available == true and .hasLogin == false and .locked == false' >/dev/null <<<"$out" \
+    || fail "a machine with no login keyring must not report itself locked: $out"
+
+# ── The daemon origin is reported, since it is the crash diagnostic ──────────
+jq -e '.daemon | test("^(pam|dbus|none|unknown)$")' >/dev/null <<<"$(run unlocked)" \
+    || fail "the daemon origin must be one of pam/dbus/none/unknown"
+
+printf 'keyring helper contract: PASS\n'