feat(app): keep the desktop signed in with an app password in the system keychain

[BryanFRD]

Last layer of #261: the desktop app stays signed in.

• Signing in mints an app password named Stashden desktop on <computer> and keeps it in the system keychain through the keyring crate (Keychain, Credential Manager, Secret Service over zbus, no system library to install).
• At launch the app reads it back and opens signed in; the sign-in form only shows when nothing is kept.
• Signing out revokes it on the server and deletes it from the keychain. An app password that was already revoked from the web app counts as signed out.
• The API gains DELETE /v1/app-passwords/current, which revokes the app password presenting the request, since an app password cannot reach the session-only revoke route. A session calling it gets 400.

Tests cover the new route: it revokes the presenting app password, leaves the others alone, and refuses a session. The keychain and the Tauri commands have no test seam here and have not been run by hand yet: worth a sign-in, a relaunch and a sign-out on the desktop before the release.

Closes #261

[ferrfleet]

One blocking finding: a failed keychain write during login leaves the app half signed in and an orphaned app password on the server (see inline). The server side (DELETE /v1/app-passwords/current, the Credential::AppPassword(id) change, tests) looks correct. A revoked password on resume ends in the 401 → sign_out path, which clears the keychain as intended.

[ferrfleet]

9721f78 is a rebase of 778901e; this PR's own changes are identical. The blocking keychain-write thread in login (app/src/main.rs:52-53) is still open, and nothing new was added to review.

[ferrfleet]

c5b7daa is another rebase with the same changes. The blocking thread on login (app/src/main.rs:52-53) is still open: a failed keychain::keep still leaves the app connected and the minted app password orphaned. Nothing new to report.

[ferrfleet]

12912e6 is a rebase with the same changes. The blocking thread on login (app/src/main.rs:52-53) is still unresolved: a failed keychain::keep still runs after connect, so the app stays connected and the minted app password is left orphaned. Nothing new to report.

[ferrfleet]

281e33c fixes the blocking keychain finding. keep runs after connect and a failure only comes back as a warning, so sign-in no longer fails and leaves an orphaned app password behind. The hostname nit is fixed with gethostname. I checked that keyring 4 with its default v1 feature sets up the native store by itself, so Entry::new needs no extra setup. Nothing new to report.