fix(ruby): encrypt the record key to the owner public key on create

[stas-schaller]

Summary

Ruby SDK: create_secret sent the record key to the server unencrypted. prepare_create_payload assigned the raw AES-256 record key to payload.record_key, while the same request carried the record data encrypted under that key. The server therefore received both a record's ciphertext and the key that opens it. This fix encrypts the record key to the application owner's public key first, matching the other SDKs.

Changes

Fixed

• prepare_create_payload reads appOwnerPublicKey from storage and wraps the record key with Crypto.encrypt_ec before it goes on the wire (KSM-1193)
• prepare_create_payload raises when the application configuration has no owner public key, instead of continuing without the encryption step (KSM-1193)

The wrap mirrors Python prepare_create_payload. Ruby's upload_file path already encrypted its file record key correctly, so only the create-record payload was affected.

The hard failure on a missing owner key is deliberate. A fallback to sending the key unwrapped would keep the defect for exactly the older applications most likely to lack that key.

Testing

cd sdk/ruby && bundle exec rspec

783 examples, 0 failures.

Three new examples in spec/keeper_secrets_manager/unit/create_secret_record_key_spec.rb assert the property on the payload bytes rather than on the code path:

1. The value in payload.record_key decrypts back to the record key under the owner private key. A control assertion first proves the keypair and the two primitives round-trip, so a failure can only mean the wrap is absent.
2. The record key genuinely decrypts payload.data, and the value on the wire is not those bytes. The first half stops the second from passing when the fixture is unrelated.
3. Deleting appOwnerPublicKey makes the call raise rather than send the key unwrapped.

All three fail on the unfixed code. The second reports expected and actual as byte-identical 32-byte strings.

Five existing create_secret examples shared a config fixture that had no owner public key, which is why this shipped twice with a green suite. The fixture now holds a real P-256 key. No assertion in those examples changed.

Live check against QA created a record, confirmed payload.recordKey is 125 bytes beginning with 0x04 rather than the 32-byte plaintext key, read the record back with its title and field values intact, then deleted the record.

Breaking Changes

None for callers whose application has an owner public key, which is every application bound by a current Web Vault or Commander. An application whose configuration lacks appOwnerPublicKey now receives an error from create_secret instead of creating a record. That path previously produced records with an unwrapped key, so it was never safe to use.

Related Issues

• Jira: KSM-1193