TPM attestation still verifies RS1 signatures, which cose-lib v5 will reject

[Spomky]

As of 4.8.0, web-auth/cose-lib brought Algorithms::getHashAlgorithmFor() and Algorithms::getOpensslAlgorithmFor() under the same acknowledgement policy as RS1::__construct(): asking either for the RS1 identifier emits an E_USER_WARNING, and as of cose-lib v5.0.0 it will throw instead.

TPMAttestationStatementSupport takes the alg declared in the attestation statement and hands it to both accessors without inspecting it:

• src/webauthn/src/AttestationStatement/TPMAttestationStatementSupport.php:145
• src/webauthn/src/AttestationStatement/TPMAttestationStatementSupport.php:379

TPMAttestationStatementSupportTest::validatingTPMAttestationWithValidECCCredentialSucceeds exercises exactly that path with a legacy TPM fixture and triggers the warning today. Unlike webauthn.cose.algorithm.RS1 and the prehashed EdDSA services removed in #962, this is not a bundle default that can simply be dropped: it is the authenticator that picks the algorithm.

Two possible outcomes:

1. Reject RS1 in TPMAttestationStatementSupport before reaching cose-lib, which makes the failure explicit and keeps the framework in control of the error contract. Existing TPM authenticators that sign with SHA-1 stop registering.
2. Let cose-lib v5.0.0 throw, which produces the same rejection but through an exception the framework does not shape.

Option 1 is preferable, in line with removing insecure defaults rather than acknowledging them. The remaining question is whether the fixture in the test suite represents authenticators still in the field, and whether the rejection needs an opt-out for the applications that must keep verifying them.

Follow-up to #962.