Reject oversized TOTP confirmation codes before validation

Problem

The existing POST /two-factor/1.0/totp callback strips whitespace and passes any string length into Two_Factor_Totp::is_valid_authcode(). The TOTP calculation derives its digit count from the submitted string, so oversized authenticated payloads can reach unnecessary large-number arithmetic instead of receiving a bounded 4xx validation response.

This was identified while adding deterministic malformed-payload fuzz coverage for #935.

Expected behavior

TOTP setup confirmation should accept only the provider's configured six numeric digits (after whitespace normalization) and return the existing invalid_key_code 400 response for malformed or oversized values before TOTP calculation.

Proposed fix

Add an explicit normalized length/numeric guard in rest_setup_totp() and retain a minimized regression test plus bounded fuzz coverage in #935.

Start in rest_setup_totp() and inspect how the POST /two-factor/1.0/totp callback normalizes and validates the code. Review the existing invalid_key_code 400 response and the malformed-payload fuzz coverage from #935, then add a minimized regression test showing that normalized non-six-digit or nonnumeric values are rejected before TOTP calculation.