Fix documentation drift from the resolved-open-questions pass

IMPLEMENTATION.md hadn't been updated after the second implementation
pass — the data model SQL was missing prev_ciphertext/prev_nonce,
can_write, and the entire vault_grants_previous table; the Rotation
section described the old "overwritten, not versioned" behavior
(the opposite of what got built); the crypto scheme section still
said "read implies write" while the Resolved design decisions section
below it said the opposite; the CLI surface listing was missing
--purge/--previous/--read-only; and "What was verified" only covered
the first verification pass, not the read-only/rollback/purge one.

README's Core model was missing any mention of the retention/purge
behavior or read/write grant scoping. INTEGRATION.md now recommends
--read-only for deploy identities specifically, now that the
capability exists.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

README.md

@@ -65,7 +65,13 @@ recipient's public key — into a live service instead of a static file:
    the payload and every other recipient's access are untouched.
 6. Rotating a secret is `keep push <vault>` again — a new random
    symmetric key, re-wrapped for every currently-granted recipient. Cheap,
-   since the recipient list rarely changes.
+   since the recipient list rarely changes. By default the outgoing
+   version is kept as a one-step rollback safety net (`keep pull
+   --previous`); `keep push --purge` skips that for compromise-driven
+   rotations where the old value should stop being retrievable, full stop.
+7. Grants distinguish read from write — a recipient can be given
+   read-only access (`keep grant --read-only`), which can pull a vault
+   but can't push to it or grant others access.
 
 Full design — data model, the atomic-grant/revoke details, and what this
 explicitly does and doesn't protect against — is in