Dual certificate support does not cover keyring-provided client certificates

ktls-utils 1.3.0 added client-side dual certificate support (commit facd084e43fc) so that a client can present a post-quantum certificate alongside a traditional RSA certificate. That work covers only certificates loaded from /etc/tlshd.conf. When an NFS client specifies alternate certificates at mount time (-o xprtsec=mtls,cert_serial=...,privkey_serial=...), the certificate and private key arrive via the .nfs keyring, and there is currently no way to provide or select a PQ certificate for the handshake.

Design questions raised in the linux-nfs / kernel-tls-handshake discussion of this gap:

• Add separate PQ certificate and PQ private key parameters to the handshake upcall, or
• Store lists of both PQ and RSA certificates and private keys under the existing keys and teach tlshd to parse both out of them (feasibility unverified).

The keyring-based mount UI itself is being reworked; whatever replaces it needs to carry PQ authentication material as well.

Reported by Sagi Grimberg and triaged by Scott Mayhew:
https://lore.kernel.org/all/fd4aaf4e-b1b7-4ca2-bc93-955c31fab317@grimberg.me/
https://lore.kernel.org/all/afUKzeUYPhb97DX4@aion/

Related: #113 (original PQC support, closed).

Start by reading commit facd084e43fc and the linked linux-nfs/kernel-tls-handshake discussions, then trace how tlshd receives certificates from the .nfs keyring for mount-time xprtsec=mtls. The design must be settled before implementation: support selecting PQ and RSA certificate material for the handshake and ensure the replacement keyring-based mount UI carries it.