Bug 2062062 - Cache the encryption key in NSSKeyManager

[jo]

ManagedEncryptorDecryptor asks NSSKeyManager for the key on every encrypt() and decrypt(), and each call is a full NSS token round-trip. add_many_with_meta() holds the store mutex for its entire run, so a bulk import kept LoginStore::shutdown() blocked on that mutex long enough to trip Desktop's 60s async shutdown timeout.

NSSKeyManager now keeps the key after the first retrieval. The primary password check still runs on every call and drops the cache when the token is found locked, so re-authentication is unchanged.

The key now lives in memory for as long as the token stays unlocked. Zeroizing would have to cover the copies passed on to ManagedEncryptorDecryptor and jwcrypto as well, so that is left as a follow-up.

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.