fix(cognito): resolve aliases in custom authentication

[dougludlow]

Why

InitiateAuth with CUSTOM_AUTH rejects an existing user when USERNAME is their email and the pool uses UsernameAttributes=["email"]. These pools store users under generated usernames, but custom authentication looks up the supplied email directly and returns NotAuthorizedException before invoking DefineAuthChallenge.

How

Resolve the supplied identifier with the existing pool-aware alias resolver after validating SECRET_HASH. Use the stored username for user lookup and the subsequent challenge flow, matching the other authentication paths while preserving secret-hash validation against the supplied identifier.

Test plan

• Service regressions cover email and stored-username lookup, rejection of unknown email addresses, and client-secret validation before alias resolution. The email and valid email-based secret-hash cases fail on the original implementation and pass with the fix.
• An official AWS SDK E2E regression creates an email-based pool and checks both identifiers against a real Fakecloud server. It intentionally omits Lambda triggers: both existing identifiers must reach the challenge-configuration error, while an unknown email must fail user lookup.

Verification

The complete cargo test --workspace run was stopped during compilation because this environment lacks Go and Terraform, which fakecloud-tfacc explicitly requires. The AWS CLI is also absent, so the full acceptance suite remains unverified locally.

Workspace Clippy on Rust 1.94.0 fails with clippy::nonminimal_bool in unchanged upstream EC2 handlers: service/image.rs:294, service/snapshot.rs:198, and service/volume.rs:456.

The conformance library test run was stopped during dependency compilation when free disk dropped below 1 GiB in this 32 GiB workspace. Its tests remain unverified locally.

---

Summary by cubic

Fixes InitiateAuth with CUSTOM_AUTH rejecting existing users when USERNAME is their email in pools configured with UsernameAttributes=["email"]. Custom auth now resolves the supplied identifier to the stored username after SECRET_HASH validation, matching the other authentication flows.

Bug Fixes

• Secret hashes are validated against the identifier the client supplied before alias resolution.
• Service and official AWS SDK E2E regressions cover email and stored-username lookup, unknown users, and validation order.

^{Written for commit 2b7cf1a. Summary will update on new commits.}