Use Valkey instead of Redis

Redis 7.4+ is RSALv2/SSPL and 8.0+ adds AGPLv3. None of the three works
for a closed-source commercial cloud service, and SSPL section 13
specifically targets offering the software's functionality as a service,
which is what a control plane does. Valkey is BSD-3-Clause, under the
Linux Foundation, forked from Redis 7.2.4.

Deciding this now rather than after step 3 of PLAN.md stands up real
infrastructure makes it free: Valkey speaks the same RESP protocol, so
`ioredis` is untouched and only names change. `REDIS_URL` becomes
`VALKEY_URL`, the exported client becomes `valkey`, and `/health`
reports a `valkey` field.

Two things deliberately do not change, documented in place so they are
not "fixed" later: the `redis://` URL scheme, which names the wire
protocol and is what every client actually parses (none understands
`valkey://`), and `ioredis` itself, which is a RESP client whose name
refers to the protocol's origin and not to the server we run.

docker-compose.yml is new, pinning valkey/valkey:8-alpine alongside
pgvector/pgvector:pg17 - the plain postgres image lacks the extension
`frame_embeddings` needs. It makes the Valkey choice concrete rather
than a note someone has to remember.

.env.example

@@ -4,8 +4,12 @@ PORT=3000
 DATABASE_URL=postgres://continuum:continuum@localhost:6432/continuum
 DATABASE_POOL_MAX=10
 
-# Redis (state + streams)
-REDIS_URL=redis://localhost:6379
+# Valkey (state + streams), NOT Redis - Redis 7.4+ is RSALv2/SSPL and 8.0+
+# adds AGPLv3, none of which we can ship commercially. Valkey is BSD-3-Clause
+# and wire-compatible. The URL scheme stays `redis://` because that names the
+# RESP wire protocol, which is what the client libraries parse - no client
+# understands a `valkey://` scheme.
+VALKEY_URL=redis://localhost:6379
 
 # Cloudflare R2 (S3-compatible)
 R2_ACCOUNT_ID=