fix: use oidcc_jwt_util:verify_signature/3, not jose_jwt:verify/2 directly

[Taure]

Summary

Closes #9.

validate_token/3's JWKS lookup always returns a #jose_jwk{keys = {jose_jwk_set, _}} (a provider can rotate keys, so it's always a set, even with one key). jose_jwt:verify/2 has no clause matching a key set, so it raised an uncaught function_clause on every genuinely-signed token. This had zero test coverage of its actual signature-verification path (only validate_claims/3 was tested in isolation), so it shipped broken.

Replaced with oidcc_jwt_util:verify_signature/3 (already in the oidcc dependency), which:

• folds over a key set correctly, matching by kid when the token's header carries one
• enforces an explicit algorithm allowlist (added here: RS256/384/512, ES256/384/512 - what every major OIDC provider actually signs ID tokens with). HMAC variants are deliberately excluded: an RSA public key is public by definition, and allowing HS* would let an attacker replay it as an HMAC secret to forge a token ("alg confusion", RFC 8725)
• rejects alg:none explicitly

Test plan

• rebar3 fmt --check, xref, dialyzer - clean
• rebar3 eunit - 17 tests, 0 failures. New: end-to-end signature verification (previously untested at any layer) - a genuinely RS256-signed token from a single- and multi-key JWKS set both validate; alg:none and a token signed by a key not in the JWKS are both rejected. Verified non-vacuous by reverting to jose_jwt:verify/2 and confirming 3 of the 4 new tests crash with the exact function_clause this fix closes, then restored.
• rebar3 ct - 12 tests, 0 failures

[Taure]

Security review came back with 0 High findings on the core fix - alg confusion, kid steering, alg:none, and wrong-key attacks all correctly fail closed, verified with real RSA/EC keys and signatures. Fixed the 3 Medium findings in 6c0a59a, all in claims validation that this fix makes reachable for the first time (every real token used to crash before reaching it):

• Added an azp check (OIDC Core 3.1.3.7) - a multi-audience token from a different client on the same shared IdP that happens to list our client_id in aud was previously accepted; now rejected unless azp matches.
• exp now requires is_number/1 - a non-numeric exp sorts above every number in Erlang term order, so the old Exp =< Now comparison would have treated it as "not expired".
• Added sub validation - nova_auth:actor()'s id field is mandatory and comes straight from sub with no fallback; a token without one produced an actor with no identity at all.
• Normalized the error contract - oidcc_jwt_util's internal error terms (two variants carry decoded token/JWS records, i.e. attacker-supplied claims) no longer cross this module's boundary; every signature failure now returns {error, invalid_signature} as before, with only a classified atom logged.

Test hardening: the two existing negative tests now assert the concrete error instead of a weak {error, _}; dropped non_strict from the meck (this suite's job is pinning the contract against the real module); added an alg-confusion regression test and a "signature-valid but claims-invalid" integration test; new claims tests for azp/exp-type/sub.

Follow-ups filed, not blocking: #11 (algorithm allowlist missing PS*/EdDSA, no per-consumer override), #12 (consider migrating to the public oidcc_token:validate_jwt/3 instead of the internal verify_signature/3). Explicitly did NOT wire JWKS refresh-on-unknown-kid per the review's own warning - the underlying oidcc worker has no rate limiting on that path, so naively wiring it would be an unauthenticated-request DoS amplifier.

Toolchain still clean: fmt/xref/dialyzer, eunit 25/25, ct 12/12.