fix(auth): correctly size keys for encrypted token passwords

[joshtrichards]

• Resolves: #

Summary

Correct the RSA key-size selection used to encrypt passwords associated with authentication tokens.

A 2048-bit RSA key using OAEP with SHA-1 can encrypt up to 214 bytes, but the existing code only selected a 4096-bit key for passwords longer than 250 bytes. Passwords between 215 and 250 bytes could therefore be assigned a key that was too small, causing password encryption to fail. Because that failure was not checked, the code subsequently attempted to Base64-encode an unset ciphertext value.

This change:

• uses the 214-byte RSA-OAEP plaintext limit when selecting between 2048-bit and 4096-bit keys;
• only generates a 4096-bit key when encrypted password storage (auth.storeCryptedPassword) is enabled;
• validates the encrypted-password storage limit before generating a key;
• clarifies that the storage limit is measured in bytes;
• checks the result of openssl_public_encrypt() before encoding or storing its output.

Checking the encryption result also provides a controlled failure when an existing token with a 2048-bit key cannot accommodate a subsequently changed, longer password. The short-to-long password transition was already a problem, as reported in #45090, but its encryption failure was not handled explicitly. Regenerating existing token key pairs to accommodate a new, longer password (and defining the associated user experience) remain outside the scope of this PR.

Tests

Added unit coverage for:

• rejecting passwords above the encrypted-password storage limit;
• allowing long passwords when encrypted password storage is disabled;
• using a 2048-bit key at the 214-byte OAEP boundary;
• using a 4096-bit key above the OAEP boundary;
• explicitly failing a short-to-long password transition when the existing token key is too small.

TODO

• Backport

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI