keymgmt: fetch CKA_ALLOWED_MECHANISMS on-demand for RSA-PSS type detection

[creatica-soft]

When an RSA key is loaded from the token (via OSSL_STORE), the CKA_ALLOWED_MECHANISMS attribute is not included in the fetch template. p11prov_obj_is_rsa_pss() then returns false for every loaded key — the encoder emits rsaEncryption instead of id-RSASSA-PSS in SubjectPublicKeyInfo.

The problem

1. PSS-restricted RSA keys have CKA_ALLOWED_MECHANISMS set to PSS-only mechanisms at generation time (p11prov_rsapss_gen).
2. When the same key is loaded back via OSSL_STORE, the store's find template only requests CKA_MODULUS and CKA_PUBLIC_EXPONENT (prep_rsa_find in store.c). CKA_ALLOWED_MECHANISMS is never fetched.
3. p11prov_obj_is_rsa_pss() reads from the object's local attribute cache — finds nothing — returns false.
4. The encoder then writes the unrestricted rsaEncryption OID in the SPKI, and the signature layer cannot determine that PSS padding is required.

The fix

Add a helper get_or_fetch_allowed_mechs() to p11prov_obj_is_rsa_pss() that:

• First checks the local attribute cache (fast path, no token I/O)
• If absent, opens a temporary session and fetches the attribute via C_GetAttributeValue
• Caches the result on the object via p11prov_obj_add_attr(), so every subsequent call hits the fast path

Testing

Tested with SoftHSM (post-2.7.0 main branch) and p11-kit 0.26.4 on Alpine 3.24. The patch restores correct RSA-PSS SPKI encoding for loaded keys — verified via the FastPKI integration suite where previously a PSS-restricted OCSP responder key had its certificate SPKI incorrectly reported as rsaEncryption.