[PM-37888] refactor: Remove unused AccountEncryptionKeys wrapper

[matt-livefront]

🎟️ Tracking

PM-37888

📔 Objective

Follow-up to #2780 and #2764, which moved all real consumers off of AccountEncryptionKeys.encryptedUserKey. This removes the AccountEncryptionKeys wrapper struct since every explicit constructor already passed encryptedUserKey: nil, and the sole consumer of an AccountEncryptionKeys value (initializeUserCrypto) only ever read cryptographicState. WrappedAccountCryptographicState can be used directly wherever AccountEncryptionKeys was used.

• Delete AccountEncryptionKeys; replace StateService.get/setAccountEncryptionKeys with get/setAccountCryptographicState returning/taking WrappedAccountCryptographicState directly
• Move the responseModel:-based factory onto WrappedAccountCryptographicState itself (WrappedAccountCryptographicState+Extensions.swift)
• Update all call sites in AuthRepository, AuthService, SyncService, KeyConnectorService, and AuthenticatorSyncService
• Remove the legacy encryptedUserKey storage in AppSettingsStore (unused since the master-password-unlock key moved to MasterPasswordUnlockResponseModel in [PM-37888] refactor: Read masterKeyWrappedUserKey from masterPasswordUnlock #2780)
• Remove the now-unused key: String? from AccountKeysResponseModelProtocol, ProfileResponseModel, and SetAccountKeysResponseModel. IdentityTokenResponseModel.key is kept — it's still used in AuthService.unlockMethod(for:) for the key connector unlock path

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the removal of the AccountEncryptionKeys wrapper in favor of using WrappedAccountCryptographicState directly across StateService, AuthRepository, AuthService, SyncService, KeyConnectorService, AuthenticatorSyncService, and the CryptoClientProtocol extension. Verified that the legacy masterKeyEncryptedUserKey storage had no remaining readers on main before removal, that new migration 7 matches the storage-key format (bwPreferencesStorage:masterKeyEncryptedUserKey_<userId>) and the pattern established by migration 6, and that the responseModel: factory moved to WrappedAccountCryptographicState preserves the original accountKeys → privateKey fallback and nil-return behavior with equivalent test coverage. Also confirmed IdentityTokenResponseModel.key is correctly retained for the key connector unlock path after key was dropped from AccountKeysResponseModelProtocol, ProfileResponseModel, and SetAccountKeysResponseModel.

Code Review Details

• ❓ : Fill-assist cache clearing added to logoutAccount appears to be an unintended merge artifact — it doesn't exist on main and duplicates FillAssistRepository.clearRules(userId:)
  • BitwardenShared/Core/Platform/Services/StateService.swift:1995-1996

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.72%. Comparing base (55c8d84) to head (21de392).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2861      +/-   ##
==========================================
+ Coverage   79.45%   81.72%   +2.26%     
==========================================
  Files        1172     1048     -124     
  Lines       75100    67768    -7332     
==========================================
- Hits        59670    55382    -4288     
+ Misses      15430    12386    -3044     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LRNcardozoWDF]

LGTM!

[claude]

❓ QUESTION: These two fill-assist lines look like a merge artifact — were they intended in this PR?

Details

The diff replaces appSettingsStore.setEncryptedUserKey(key: nil, userId: knownUserId) with two fill-assist clears that don't exist on main. main's logoutAccount has no fill-assist cleanup — PM-38443 (#2811 added it here, #2812 moved it out) relocated that responsibility to FillAssistRepository.clearRules(userId:), which AuthRepository.logout already calls before stateService.logoutAccount.

So on the normal logout path this is now duplicated, and it also isn't mentioned in the PR description for an otherwise pure AccountEncryptionKeys refactor. If it wasn't intentional, dropping both lines restores parity with main.

(Note: deleteAccount() calls logoutAccount directly without going through AuthRepository.logout, so if the intent was to cover that path, a comment or a call to clearRules would make it explicit — and the keychain fillAssistRulesFingerprint is still left behind either way.)