redisstore: add application-level encryption for sensitive persisted data

Problem

The Redis adapter currently stores session snapshots, event records, schedules, metadata, tool-call records, and Redis-workspace file bytes without application-level encryption. Verified Redis TLS protects transport, and a managed service may encrypt disks/backups, but a Redis credential holder or compromised Redis service can read application plaintext.

There is also no cryptographic integrity protection for persisted snapshots/events beyond format and structural validation.

Proposed direction

Design application-level envelope encryption for sensitive payloads using an AEAD construction. Keep keys outside Redis in a supported KMS/key-management boundary. Prefer per-record data-encryption keys wrapped by a versioned key-encryption key, with tenant/session, record type, identity, and revision bound as associated data. Define which minimal indexes remain plaintext and document their leakage.

This requires an ADR before implementation because it affects storage formats, migrations, key loss/recovery, rotation, multi-replica operation, backup restore, and external driver compatibility.

Acceptance criteria

• A Redis administrator/dump cannot recover protected prompt, response, tool, workspace, or schedule content without KMS access.
• Tampering, swapping records between sessions/tenants, truncation, and unsupported key versions fail closed.
• Key material is never stored in Redis, logs, snapshots, command arguments, or model-visible environments.
• Online rotation and restore procedures are documented and tested.
• Existing plaintext records have an explicit migration/compatibility policy.
• Metadata intentionally left plaintext is inventoried and documented.
• Failure behavior for unavailable KMS and permanently lost keys is explicit.

Start by locating the Redis adapter and its persistence paths for session snapshots, events, schedules, metadata, tool-call records, and workspace file bytes. Produce the required ADR before implementation, covering AEAD envelope design, KMS boundaries, associated data, plaintext indexes, rotation, migration, restore, and failure behavior. Done means the ADR and its documented, tested procedures address every acceptance criterion.