Allow for .pem and .key client cert authentication

[aysiu]

Not necessarily the ideal implementation, but we've had a brief Slack discussion about it, and it sounds as if you might be able to make additional tweaks to make it better.

[rodchristiansen]

Thanks for the PR, @aysiu! Helps me cover ground I haven't yet. As we chatted about doing extra tweaks to carry the idea forward, I pushed a follow-up commit directly to your branch (672fe33) that does a few things:

Fixes to the PEM path you added

1. Gate file-based cert loading behind auth.use_mtls. In the original patch, setting CRYPT_CLIENT_CERT_PATH alone would silently enable mTLS even when use_mtls was false, and if you set both cert-store options and PEM paths, two different client certs got added to the same handler. Now everything routes through a single GetClientCertificate(AuthConfig) method that tries strategies in priority order and stops at the first success.
2. Route the new fields through ConfigService.GetX() helpers. The original read CRYPT_CLIENT_CERT_PATH / CRYPT_CLIENT_KEY_PATH inline, which skipped the registry / CSP / OMA-URI Intune deployment path that every other auth field goes through. I added GetClientCertPath() and GetClientKeyPath() helpers matching the pattern of GetCertificateSubject().
3. Replace the obsolete new X509Certificate2(byte[]) ctor — it triggers SYSLIB0057 on .NET 9+ — with X509CertificateLoader.LoadPkcs12. The PFX round-trip on Windows is still needed so HttpClient can use the key during the TLS handshake; the byte buffer is now cleared after use, and the resulting cert is tracked on the instance so Dispose() cleans it up.
4. Distinct error messages for each failure mode (file missing, parse failure) so operators can self-diagnose configuration problems.

New: PFX + Credential Manager strategy

I also added a third mTLS strategy that's more secure than PEM+key files, after a discussion about security trade-offs: a .pfx on disk whose passphrase is pulled from Windows Credential Manager at load time. The passphrase never touches YAML, env vars, or the registry. Provisioning is a one-liner:

cmdkey /generic:CryptPfxPassword /user:cryptescrow /pass:<secret>

New config fields are pfx_path / pfx_password_credential (YAML), CRYPT_PFX_PATH / CRYPT_PFX_PASSWORD_CRED (env vars), and matching registry values for CSP deployment.

Implementation is a LibraryImport wrapper over advapi32!CredReadW in Services/CredentialManager.cs — no new NuGet dependency. <AllowUnsafeBlocks>true</AllowUnsafeBlocks> is required by the LibraryImport source generator and was added to the csproj.

Priority order is: GetClientCertificate now tries, most-secure-first: PFX+CredMgr → PEM+key → Cert Store thumbprint → Cert Store subject. First match wins. Failures fall through, so a typo'd path doesn't nuke cert resolution.

README updated to rank the three mTLS strategies by security with provisioning examples for each, and the new env vars / registry values are documented.