rbw edit corrupts entries that have an individual encryption key

[NanShanFish]

rbw edit corrupts entries that have an individual encryption key

Problem

Running rbw edit on an entry that has its own encryption key (an entry with a
key field, e.g. organization/shared items, or items with an item key that may
have been created by the browser extension) silently corrupts the entry. After
the edit, other clients silently fail to display the entry, and rbw fails with
an invalid MAC error, making all functionality unusable.

Steps to reproduce

1. Have an entry with a key field (individual item key)
2. rbw edit <entry> and change the password (or notes)
3. Observe:
   • rbw get <entry> fails with
     failed to decrypt: failed to decrypt encrypted secret: invalid mac
   • other clients no longer display the entry / the password and notes fields
     cannot be decrypted
4. rbw login / rbw sync do not help (the corruption lives server-side)

Root cause

The edit path ignores the entry's individual key in two places:

1. commands.rs re-encrypts the new password/notes with
   crate::actions::encrypt(plain, org_id) — which encrypts with the user's
   master key (or org key), not with the entry's item key
2. The PUT /api/ciphers/{id} request built in api.rs (CiphersPutReq)
   does not include the cipher's key field, so the server keeps the old
   (now stale) item key

Result: the item's name/username remain encrypted with the item key, while the
new password/notes are encrypted with the master key, but the item is still
tagged with the item key. No single key can decrypt all fields -> invalid mac
for password/notes on every client.

For a personal entry this is especially bad: the server keeps the now-orphaned
key field, so recovery requires a direct database edit.

Expected behavior

rbw edit should encrypt the new field values with the entry's item key (when
present) and preserve/send the key field on update, mirroring the web vault
and official clients.

Notes

• Reading keyed entries works fine today (the decrypt path unwraps the item
  key); only the write/edit path is affected
• A side effect worth noting: a single undecryptable entry causes
  rbw list / rbw get / rbw remove to fail for the whole vault, because
  entry decryption errors are propagated instead of skipping the entry

[Mic92]

I fixed the issue in my pr