refactor: tidy auth token validation and scope handling

[DaleSeo]

On the validation side, we're moving the Claims type and the algorithm mapping out of the long validate method. Now, the function reads more clearly as a "try each server, resolve key, decode, check claims" loop, and we can unit-test the claim logic directly. We’re also replacing the VerificationKey struct with a simple (Jwk, String) tuple returned from KeyResolver::resolve_key.

On the scope side, we're pulling the scope-sufficiency check into a new ScopeMode::is_satisfied_by method. This way, the scope tests will use the actual logic instead of a copied version. We’re also rendering the scope_mode header through ScopeMode::as_str instead of going through a JSON round-trip.

[apollo-librarian]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: 4c25b167fe8a540f1aee5c93
Build Logs: View logs

---

✅ AI Style Review — No Changes Detected

No MDX files were changed in this pull request.

Review Log: View detailed log

This review is AI-generated. Please use common sense when accepting these suggestions, as they may not always be accurate or appropriate for your specific context.

[github-actions]

⏭️ Changeset check skipped via label

[jerelmiller]

Naive question, but what does the tuple approach provide thats superior to the VerificationKey struct approach? Is it just easier destructuring?

[DaleSeo]

I went with a tuple because VerificationKey felt like an incomplete name for a struct containing both the JWK and the issuer. I couldn't come up with a better name that wasn't overly wordy, so I thought I'd just opt for the tuple instead. :)