Fix algorithm confusion that allows JWT forgery via RSA JWK as HMAC key

GHSA-q843-6q5f-w55g: an RSA JWK without an "alg" parameter was accepted
as the verification key for HS256/384/512 tokens. Because the jwk_item_t
union shares storage between provider_data (RSA EVP_PKEY *) and
oct.{key,len} (HMAC bytes/length), the OpenSSL HMAC path read a
zero-length key and produced a successful verification for any token
signed as HMAC("", header.payload). This let an attacker forge tokens
using only the public JWKS.

Bind algorithm acceptance to the JWK's actual "kty" rather than its
optional "alg" hint, in three layered places:

* jwt-private.h: new jwt_alg_required_kty() helper providing the
  authoritative JWA-algorithm to JWK-kty mapping.
* jwt-common.c: __setkey_check() now rejects any setkey() / verify
  callback that pairs a non-none algorithm with an incompatible kty.
  This is the primary fix and runs at both setkey and post-callback.
* jwt-verify.c: __verify_config_post() re-checks kty once jwt->alg is
  bound from the token, blocking malformed JWKs whose own alg hint
  disagrees with their kty.
* jwt.c: __check_hmac() defensive backstop in the single chokepoint
  used by all three crypto backends; refuses any non-oct key for HMAC.

Tests added in jwt_security.c cover the original PoC, the realistic
JWKS callback exploit pattern, all three HS sizes, RSA/EC/OKP keys
mis-targeted at HS256, and the malformed-JWK defensive verify path.
A few existing tests (hs256_token_failed, verify_es256_bad_sig,
sign_es256_bad_sig, rsa_ec_short) were updated; they previously
documented the vulnerable behavior under the guise of "different ways"
of failing and now assert the correct earlier rejection.

Signed-off-by: Ben Collins <bcollins@libjwt.io>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>