Replace keys_have_alg with has_key_for_signing_alg in JWKS stage
RFC 7517 makes the JWK `alg` field OPTIONAL, and the atproto OAuth
profile does not override that. The old `keys_have_alg` check flagged
any per-JWK `alg` omission as a spec violation, which was neither
grounded in a spec requirement nor useful: what actually matters is
whether the JWKS contains at least one key usable with the client's
declared `token_endpoint_auth_signing_alg` for `private_key_jwt`.
The new check considers a key compatible if either its explicit `alg`
matches the declared signing alg, or (when `alg` is absent) its `crv`
structurally matches the signing alg (P-256 <-> ES256, secp256k1 <->
ES256K). Missing `token_endpoint_auth_signing_alg` on a confidential
client is now surfaced directly on this check.
The design plan is updated to reflect the refactor since we are still
in the initial implementation phase of the oauth client subcommand.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>