fix(deep-link): deliver cold-start auth links via pending state

[Blankll]

The bug

A sqlkit://auth sign-in link that launches the app silently dropped the token. The cold-start branch in setup parsed the URL and called emit("sqlkit://auth")\) — but the webview hadn't started loading yet, and Tauri events are not queued. The frontend's listen()only registers inonMounted`, several hundred milliseconds later. The URL arrived, the token was parsed, the handoff to the frontend never happened.

The fix

Park the parsed payload in a PendingAuthState (managed Mutex<Option<AuthPayload>>) instead of firing it into the void:

• Cold start: setup writes the payload; the frontend pulls it via a new consume_pending_auth command after registering its listeners (pull is a query, so no timing dependency).
• Running instance: the deep-link://new-url listener now double-writes — stores to the pending slot and emits — covering the window where the app just started and the frontend is still loading.
• consume() takes-and-clears, so a delivered token can never be replayed.
• The frontend funnels both delivery paths through one idempotent handleAuth (setAuth → refreshEntitlement → ensureActivated), so double delivery is harmless.

Listener registration is ordered before the pull, so an event arriving between the two is still received.

Verification

• cargo check / cargo test --lib (385 passing)
• npm test (533 passing) / lint:check / npm run build (vue-tsc)

Manual check that remains: on a packaged Linux build (the .desktop template with %u from #151), click a sqlkit://auth?... link from a cold state and confirm sign-in completes.