Incorrect typing on JwtAuth::generateToken, hard to troubleshoot missing/incorrect keys

Since we are working on a new major version here, I wonder if it would be clearer/simple to return NULL on failure so the type hint can be ?string. This would be the simplest and would match the return value type hint on the underlying transcoder.

Or would it even be better to throw an exception?

Switch to ?string and simpler check for empty return. Needs a test

Used claude to generate a Functional test:

added the functional test at web/modules/drupal/jwt/tests/src/Functional/JwtAuthIssuerControllerTest.php.   
                                                                                                                                     
  Test coverage — four cases, each exercising a code path that the 3.x→branch diff changed:                                                                                  
                                                                                                                                                                             
  1. testTokenResponseValidKey — logs in via cookie, GETs jwt/token, asserts 200 + token key + token decodes to the user's UID.                                              
  2. testTokenResponseInvalidKey — calls setShortHmacKey() to overwrite jwt_test_hmac with a <32-byte value (so JwtTranscoder::setSecret() rejects it and generateToken()    
  returns NULL), then asserts 500 + error message containing "set a key in the JWT admin page".                                                                              
  3. testLoginResponseIncludesJwtWithValidKey — POSTs to user.login.http (_format=json), asserts access_token is present.
  4. testLoginResponseHasNoJwtWithInvalidKey — same login POST after setShortHmacKey(), asserts 200, no access_token, but current_user still present (the new if             
  (!empty($decoded['access_token'])) guard preserves the underlying login payload).                                                                                          
                                                                                                                                                                             
  A note on the "invalid key" approach: pointing jwt.config:key_id at a non-existent key id was tempting but would leave JwtTranscoder::$algorithmType (typed string,        
  non-nullable) uninitialized and throw a TypeError from getKey() rather than reach the controller's null-token branch. Overwriting the existing key with a too-short value
  reaches the intended path because setKey() still calls setAlgorithm() before setSecret() rejects the value.