fix(auth): key device metadata by inputUsername so alias sign-in pools remember devices

[dmorrow]

Issue

Related to #4196, which fixed the device-metadata keychain key for the write path (ConfirmDevice) but left several read paths keyed off a different value.

Description

On a user pool configured with alias sign-in (e.g. email alias), RespondToAuthChallenge returns a USERNAME challenge parameter equal to the user's sub, not the value the caller signed in with. #4196 made ConfirmDevice store device metadata under signedInData.inputUsername (the caller-supplied username), but the sign-in actions still read that metadata back using the echoed USERNAME (the sub). The read key never matched the write key, so:

• DEVICE_KEY was omitted from the password-verifier response, and Cognito treated every sign-in as a new device — MFA on every sign-in, and a new device record accumulating per attempt.
• On pools where the username is the sub, the two values coincide, which is why this isn't seen everywhere.

This PR aligns every device-metadata read (and the two deviceNotFound deletes) with the inputUsername used by the write, across the SRP, challenge, and device-SRP flows:

• VerifyPasswordSRP — read and the deviceNotFound delete now use inputUsername. (The delete previously used the echoed username; when a stored device key was stale, Cognito returned ResourceNotFoundException, the recovery path deleted the wrong keychain entry, and the retry re-read the same stale key and looped indefinitely.)
• VerifySignInChallenge — both reads and the deviceNotFound delete now use challenge.inputUsername ?? username.
• UserPoolSignInHelper — carries inputUsername ?? username into .initiateDeviceSRP, so InitiateAuthDeviceSRP looks the metadata up (and re-sends DEVICE_KEY) under the right key. Without this the device-SRP flow fails with Missing required parameter DEVICE_KEY.
• VerifyDevicePasswordSRP — reads metadata with inputUsername; the outgoing request still sends username (the echoed value), which is what Cognito expects.

Nothing sent to Cognito changes semantically — username still supplies the request USERNAME on every request; only the keychain lookups moved to the value the metadata was written under.

Verification

Manually verified end-to-end on a real device against an alias-sign-in pool (us-east-1 email alias, MFA via email OTP):

• Fresh device → MFA challenge → rememberDevice → subsequent sign-in takes DEVICE_SRP_AUTH and completes with no MFA.
• Stale local device key → a single deviceNotFound recovery + retry, then a normal MFA challenge (no infinite loop).
• Device removed / password reset → MFA challenge, then re-remembered on confirm.

General Checklist

• Added new tests to cover change, if needed
• Build succeeds with all target using Swift Package Manager
• All unit tests pass
• All integration tests pass
• Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)
• Documentation update for the change if required
• PR title conforms to conventional commit style
• New or updated tests include Given When Then inline code documentation and are named accordingly testThing_condition_expectation()
• If breaking change, documentation/changelog update with migration instructions

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[dmorrow]

@thisisabhash This fixes a bug in production. Would it be best for me to submit a bug report as well? Our iOS users devices are never saved, leading to MFA every time.

[harsh62]

All checks passed on #4263.