[PM-39454] feat(km): reject unlock data whose user key id does not match the stored one

[quexten]

When changing the password or changing KDF settings, the user-key MUST NOT be changed. Thus, we add the key id in the unlock data so that the server can validate and assert it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.90%. Comparing base (dc7519e) to head (1dc7f99).

Additional details and impacted files

@@                      Coverage Diff                      @@
##           km/user-key-id-05-write-path    #8111   +/-   ##
=============================================================
  Coverage                         62.90%   62.90%           
=============================================================
  Files                              2304     2304           
  Lines                            100400   100412   +12     
  Branches                           9041     9043    +2     
=============================================================
+ Hits                              63152    63165   +13     
+ Misses                            35062    35061    -1     
  Partials                           2186     2186           

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This change closes the remaining key-id gaps on the write path: ChangeKdfCommand now asserts the unlock data's key id is unchanged before delegating to MasterPasswordService (mirroring the existing cross-layer salt assertion, and documented as such), and BaseRotateUserAccountKeysData.ValidateContainedKeyIdMatches verifies that the key id carried in master password unlock data names the same key as the rotation's authoritative UserKeyId for both MasterPasswordRotateUserAccountKeysData and PasswordChangeAndRotateUserAccountKeysData. I traced both rotation entry points end to end: the comparison is request-internal, so it is independent of the BaseRotateUserAccountKeysAsync ordering that assigns user.UserKeyId; it runs before any persistence; TDE and Key Connector rotations carry no unlock key id and are correctly untouched; and the skip-when-contained-is-absent / reject-when-only-the-unlock-side-reports-one asymmetry is the safe direction, since the rotation's key id is the only value persisted. KeyId compares by value via Equals/==/!=, the [UserKeyId] attribute keeps malformed ids out before these checks, and the new unit tests plus the ordering-dependent integration test (unlock data keeps the fixture key id, rotation key id is overridden) fail loudly rather than silently if the setup order is ever changed.

Code Review Details

No new findings. Both maintainability threads from the earlier review pass are resolved, and the feature is unreleased (KeyId does not exist on main), so the stricter rejection introduces no client compatibility risk.