fix(auth): read device metadata with the caller's username during sign-in

[dmorrow]

Based on #2 (upstream sync) so the diff here is just the fix — retarget to main once #2 merges.

The bug

ConfirmDevice stores device metadata under signedInData.inputUsername — the username the caller signed in with — but the sign-in flow read it back with parameters["USERNAME"], the value Cognito echoes. On a pool with alias sign-in that echoed value is the sub, so the read never matched the write:

IntializeSignInFlow → deviceMetadata(username: "user@example.com")   ✅ found
InitiateAuth response → USERNAME: 536be3c7-…                          (sub)
VerifyPasswordSRP  → deviceMetadata(username: "536be3c7-…")           ❌ No Keychain item found
                   → "No existing device metadata found."
…MFA challenge…
ConfirmDevice      → stores under user@example.com                    ← email again

With no metadata loaded, buildInput omits DEVICE_KEY (InitiateAuthInput+Amplify.swift:135), so Cognito treats every sign-in as a new device: fresh NewDeviceMetadata, a new device record, and an MFA challenge — forever. One affected user had accumulated 50 device records, one per sign-in, every one with lastAuthenticatedDate == createdDate.

Pools where the username is the email are unaffected, because the two values coincide — which is why this wasn't caught by the tests added in b3b8320.

The fix

Read with the same value the write uses:

File	Was	Now
VerifyPasswordSRP.swift	for: username	for: inputUsername
VerifySignInChallenge.swift (challenge response)	for: username	for: challenge.inputUsername ?? username
VerifySignInChallenge.swift (handleConfirmSignInWithPassword)	for: username	for: challenge.inputUsername ?? username

Nothing sent to Cognito changes. username still supplies USERNAME on every request; only the keychain lookups moved.

Known gap

InitiateAuthDeviceSRP and VerifyDevicePasswordSRP still look up by the echoed username. That path only runs once Cognito accepts a device key — i.e. it becomes reachable because of this fix. If it misses there, VerifyDevicePasswordSRP hits its guard case .metadata and throws SRPError.calculation, which fails sign-in rather than falling back to MFA. Deliberately left out of this PR; the two candidate fixes are threading inputUsername through the DeviceSRP events/state, or having ConfirmDevice write under both usernames.

Testing

Compiled (swift build --target AWSCognitoAuthPlugin) before the upstream merge; not re-built or exercised against a live pool since. InputUsernameDeviceKeyTests.swift is the right home for a regression case where parameters["USERNAME"] differs from the input username — not added here.

🤖 Generated with Claude Code