encrypt with item key when editing keyed entries

[NanShanFish]

Problem

rbw edit corrupts entries that have an individual encryption key (an entry
with a key field). After editing such an entry, its password/notes can no
longer be decrypted by any client (including rbw), failing with invalid mac.
See #364.

Root cause:

• The edit path re-encrypts the new password/notes with the master key (or org
  key) via the encrypt action, ignoring the entry's item key
• CiphersPutReq (PUT /api/ciphers/{id}) never sends the cipher's key field,
  so the server keeps the stale item key

The result is a mixed-key cipher: name/username encrypted with the item key,
password/notes encrypted with the master key, tagged with an item key that
matches neither. No client can decrypt the whole item.

Changes

• src/protocol.rs: add entry_key to Action::Encrypt
• src/bin/rbw/actions.rs: pass entry_key through the encrypt action
• src/bin/rbw-agent/actions.rs: when entry_key is provided, unwrap the item
  key (decrypt it with the master/org key) and encrypt with the item key
  instead of the master key. Extracted as a testable encrypt_with_key helper
• src/bin/rbw-agent/agent.rs: dispatch the new entry_key argument
• src/bin/rbw/commands.rs: the edit flow passes the entry's key when
  re-encrypting, so keyed entries are edited with their own key
• src/api.rs: add key to CiphersPutReq and send it in Client::edit, so
  the server keeps the correct item key
• src/actions.rs: thread key through edit / edit_once
• Tests: round-trip test proving data encrypted via the item key decrypts only
  with the item key (and not with the master key)

Result

Editing an entry with an individual key now encrypts the new field values with
the entry's item key and sends the key field on update, so all clients
decrypt the item correctly. Entries without a key field behave exactly as
before.

Testing

• cargo test (all targets) passes
• cargo fmt / cargo clippy --all-targets clean

Fixes #364