Improve secret key handling using zero-copy memfd_secret isolation

[NilanjanDaw]

Implement a zero-copy security architecture to protect KEM and Binding private keys stored inside secure memfd_secret mappings (Vault). This change eliminates standard stack and heap process memory residency of raw private key material during active cryptographic lifecycles:

1. Scoped Vault Borrows: Replaced the copy-heavy Vault::get_secret() with the closure-based Vault::with_secret() scoped borrow pattern, preventing standard heap re-allocations.
2. Lifetime-Bound Key References: Transitioned crypto traits and downstream APIs to consume borrowed PrivateKeyRef<'a> structures linked directly to Vault mapping lifetimes.
3. Stackless Cryptographic FFI: Bypassed standard array-owning PrivateKey value types during X25519 decapsulation, calling raw FFI bssl_sys::X25519 pointers. Derived shared secrets are written directly into heap-allocated SecretBox destinations, ensuring zero stack footprint.
4. Direct-to-Vault Keypair Generation: Implemented stackless keypair generation directly inside pre-allocated Vault instances via ScopedEvpHpkeKey and raw BoringSSL key generation FFI extraction.
5. Library & Downstream Integration: Propagated zero-copy patterns to KeyRecord and downstream handlers (key_protection_service and workload_service). Added test-utils constructors to safely mock KeyRecords in tests.

All unit and integration tests pass successfully.

[atulpatildbz]

ScopedEvpHpkeKey places the full EVP_HPKE_KEY struct including private_key bytes on the Rust stack as a local variable via std::mem::zeroed, so this isn't genuinely stackless.

The Drop impl (line 275) also provides no real zeroization: EVP_HPKE_KEY_cleanup is a no-op in BoringSSL right now (ref).

Since bssl_sys::X25519_keypair is available and Vault::write_secret accepts a FnOnce(&mut [u8]) closure, we could skip the HPKE wrapper entirely and generate directly into the vault:

let mut vault = Vault::new_empty(32)?;
unsafe {
    vault.write_secret(|priv_buf| {
        bssl_sys::X25519_keypair(pub_key_buf.as_mut_ptr(), priv_buf.as_mut_ptr())
    });
}

[NilanjanDaw]

Thats a great point, updated to directly use bssl_sys::X25519_keypair

[atulpatildbz]

unsafe isn't needed here right?

If the closure f contains FFI calls (which are indeed unsafe), the responsibility for maintaining safety lies inside the closure, at the point where the FFI call is made.

[atulpatildbz]

slice &[u8] can be of any length. and the length is only known at runtime.
this is passed to bssl_sys::X25519_public_from_private which expects the 2nd argument to point to 32 byte memory. see https://github.com/google/boringssl/blob/ef4f3c2197f90c96a44716aedaac55a10cb4e479/include/openssl/curve25519.h#L58

this is safe for now since to_public is only called from decaps_internal. where we check for self.0.len() != 32. but there's no compile time check.

And to_public itself should enforce this.

1. Instead of wrapping a dynamically-sized slice &[u8], we should wrap a statically-sized array reference &[u8; 32].
2. After this self.0 would be guaranteed to point to 32 byte memory. we can remove Result return type
3. in key_types.rs use try_into() conversion when we construct X25519PrivateKeyRef

By doing this, it becomes impossible to compile code that constructs a X25519PrivateKeyRef with a wrongly-sized slice

[atulpatildbz]

we should be added new tests:

1. That generate_keypair() actually populates the Vault with a key matching the returned public key (public_from_private round-trip).
2. That a randomly written byte cookie in the Vault round-trips through with_secret (you have this for Vault::new but not for new_empty + write_secret).
3. That the public key bytes returned correspond to the private key in the Vault (i.e., X25519_public_from_private(vault_priv) == returned_pub). A simple test that decaps a fresh keypair would catch wiring bugs.