feat(passkey): Add GET /passkey/wraps/{credentialId}

[nshirley]

Because

• Passwordless sign-in needs the wrap envelope to unseal kB, and the mfa:passkey token minted from a passkey assertion is what authorizes the read.
• A wrap written before the account's current kB unseals a key Sync no longer uses.

This pull request

• Adds GET /passkey/wraps/{credentialId}, gated on an mfa:passkey token bound to the credential being fetched, and on the passwordless sync flag. Rate-limited as passkeyWrapsGet.
• 401s when the token is not bound to the requested credential (errno 223); 404s for a credential with no wrap (234) and a wrap older than keysChangedAt (new errno 236).
• Adds encodePasskeyWrapEnvelope, keyed off the v1 widths so a new field cannot be dropped by a stale mapping.
• Records no security event: this runs on every passwordless sign-in.

Issue that this pull request solves

Closes: FXA-13143

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).
• I have manually reviewed all AI generated code.

How to review (Optional)

• feat(passkey): Mint an MFA token from passkey sign-in #21137 has landed, so this is now based on main and the diff is only the GET endpoint.
• isBoundTo is shared with the write path, so both routes enforce the credential binding identically. PasskeyService.getPasskeyWrap already landed in FXA-13140.
• isWrapStale is written inverted (!(createdAt >= keysChangedAt)) so a NaN keysChangedAt withholds rather than serves — every comparison against NaN is false, and this is the only control enforcing the invariant.

Other information (Optional)

• passkeyWrapsGet has no rate-limit rule configured yet, matching passkeyWrapsCreate and passkeysList. The call site is in place for when one is added.

[nshirley]

PR is currently targeting a non-main branch because it's built off of work from that branch. I'll re-target main when the other branch lands

[nshirley]

It's not 'business' logic to omit the cid check similar to how the POST endpoint does, so it's a bit odd to have a test for it... but, I could see a case where some frontend logic goes to check for an existing wrap on a different credential, then we later decide to lock down the endpoint more and break that inadvertently. This just gives us an early warning if that ever happens and costs us nothing

[nshirley]

I was thinking about this more last night, and I honestly cannot think of any case where we would want to allow fetching a warp with a different credentialId than what granted the token. And, if we did hit a case where we're minting a JWT with a different credential than the wrap we're requesting, that's a separate bug that should be fixed - I'm going to add back the cid check similar to the POST endpoint and then drop this test.