Fix ASC sign-in never remembering "Trust This Browser"

[24leviii-arch]

Summary

AppleIDLoginSheet's ASCWebView configures its WKWebView with .nonPersistent():

let config = WKWebViewConfiguration()
config.websiteDataStore = .nonPersistent()

That discards every cookie — including Apple's own device-trust cookie — the moment the sign-in sheet closes. Since the WebView has no memory between launches, idmsa's 2FA flow has no choice but to re-verify and re-show "Trust This Browser" on every single sign-in. Checking that box can never have any effect, because there's nothing left afterward for it to persist into. It's not a case of the trust not "sticking" — there's no storage for it to stick to at all.

Fix

Swap the ephemeral store for a persistent, identifier-scoped one:

private static let persistentStoreID = UUID(uuidString: "6F1B2C3D-4E5F-4A6B-8C7D-9E0F1A2B3C4D")!
...
config.websiteDataStore = WKWebsiteDataStore(forIdentifier: Self.persistentStoreID)

WKWebsiteDataStore(forIdentifier:) gives the WebView its own persistent, on-disk data store that's fully isolated from the user's actual Safari data (nothing shared, nothing leaked), but does survive between app launches — so cookies and Apple's device-trust state can actually persist the way they would in a normal browser. Available since macOS 14, which matches this project's deployment target.

The cookie-capture flow that feeds ASCWebSessionStore (polling for myacinfo, then extracting cookies via the olympus/v1/session call) is completely unchanged — this only changes where the WebView's own state lives.

Testing

• swift build --target Blitz succeeds with this change (verified locally).
• Minimal, single-file diff; no changes to the cookie-extraction/session-store logic.

Fixes the recurring "asks to trust the browser every time, trusting it does nothing" issue reported by a user.