Cover the Thumbprint key reference in both directions

The matrix had BinarySecurityToken, SubjectKeyIdentifier and IssuerSerial but no Thumbprint row, and the
oracle already supported the reference on both sides. The PHP-outbound row is the one that matters: the PHP
side emitted its KeyIdentifier in the WSS 1.1 namespace, where no KeyIdentifier element is declared, and
WSS4J answers "Unsupported KeyInfo type". A PHP round trip could not catch that, because the PHP reader
accepts either namespace on the way in.

Author: veewee

tests/Wsse/SignatureInteropTest.php

@@ -87,6 +87,10 @@ public static function phpKeyRefProvider(): iterable
         yield 'BinarySecurityToken' => [Outbound\KeyReference\KeyRef::BinarySecurityToken, ''];
         yield 'SubjectKeyIdentifier' => [Outbound\KeyReference\KeyRef::SubjectKeyIdentifier, ''];
         yield 'IssuerSerial' => [Outbound\KeyReference\KeyRef::IssuerSerial, '?disableBsp=true'];
+        // Thumbprint resolves from the recipients keystore too. This row exists because the PHP side once
+        // emitted the KeyIdentifier in the WSS 1.1 namespace, which no conformant peer resolves: only a
+        // PHP-outbound row catches that, since the PHP reader accepts either namespace on the way in.
+        yield 'Thumbprint' => [Outbound\KeyReference\KeyRef::Thumbprint, ''];
     }
 
     #[DataProvider('phpKeyRefProvider')]
@@ -133,6 +137,7 @@ public static function javaKeyRefProvider(): iterable
         yield 'BinarySecurityToken' => ['BinarySecurityToken'];
         yield 'SubjectKeyIdentifier' => ['SubjectKeyIdentifier'];
         yield 'IssuerSerial' => ['IssuerSerial'];
+        yield 'Thumbprint' => ['Thumbprint'];
     }
 
     #[DataProvider('javaKeyRefProvider')]