Generate exoharness secret key and nonce from a CSPRNG

[Alexsun1one]

What changed

random_master_key and random_nonce in crates/exoharness/src/secrets.rs
built the AES-256-GCM key and nonce from Uuid::new_v4() bytes. A v4 UUID has
fixed bits (the version nibble at byte 6 and the variant bits at byte 8), so the
32-byte key was not uniformly random (~244 bits, with fixed bits at known
offsets) and the 12-byte GCM nonce was effectively 90 bits, not 96.

Both now fill the buffer directly from the OS CSPRNG with getrandom::fill.

This is a hygiene fix, not an exploit. The UUID bytes were already CSPRNG-backed
on these targets so nothing was crackable. The reason to change it: key material
should not carry fixed structural bits, and it should not rely on uuid's v4 RNG
being a CSPRNG, which uuid does not promise as an API guarantee.

Notes

• No format change, no migration. EncryptedSecret serialization and the
  nonce-length check are untouched, the nonce is still stored per ciphertext, and
  the master key is still read back as-is from the keychain or key file. Existing
  secrets still decrypt.
• getrandom is added as an optional dep under basic-backend. 0.3.4 was already
  in the lockfile (via keyring/turso/uuid), so the lock gains one edge and no new
  crate compiles.
• I used getrandom directly instead of aes-gcm's generate_key / Generate
  helpers. Those bottom out in the same getrandom crate, and calling it directly
  keeps the [u8; 32] the on-disk format already uses, without coupling the key
  provider to the AEAD type.

Out of scope

• The file-backed master key is still 0600 plaintext on disk (no OS keyring on
  Linux). Not changed here.
• Nonce uniqueness still relies on random 96-bit nonces under a long-lived key.
  Fine at this scale, but a separate topic if write volume grows.

Testing

cargo build, cargo clippy -p exoharness --features basic-backend --all-targets -- -D warnings, cargo fmt --check, and cargo test -p exoharness --features basic-backend all pass (15 tests, including the existing
secrets_are_encrypted_at_rest). Added three tests in secrets.rs: key
distinctness, a nonce check that would catch the old UUID derivation, and an
encrypt/decrypt round trip with distinct nonces.