Add opt-in Valkey deployment profile + scheduled CI lane for the valkey backend

## Summary

Buzz's deployment surfaces all pin `redis:7-alpine` — the dev compose file, the self-host compose bundle (`deploy/compose/`), and the Helm chart (which pulls a Redis subchart for evaluation installs). The application is store-agnostic: the only seam is the `REDIS_URL` connection string consumed by `redis-rs`. But nothing in the repo tells an operator that a Valkey endpoint works, no test proves it, and no configuration option selects it.

I'd like to propose making **Valkey a documented, tested, opt-in deployment option** for the key-value backend — everything additive, with Redis remaining the default.

## Why

**License alignment.** Buzz is Apache-2.0, but Redis images from 7.4 onward ship under RSALv2/SSPL, so the default self-host stack quietly includes a non-permissive component. This is the same license-alignment concern already raised for the object-storage layer in #2618 (proposing an Apache-2.0 S3 backend). The key-value layer has the same shape of problem and no proposal yet. Valkey is BSD-3-Clause.

**Operational reality.** A growing share of managed key-value deployments — including AWS ElastiCache — run the Valkey engine. Operators pointing Buzz at those endpoints today are running an untested configuration with no signal from the project that it's safe. The risk concentrates in Buzz's subtler usage: pattern-based pub/sub for cross-pod cache invalidation, atomic set-if-absent for NIP-98 replay protection, and the five server-side Lua scripts (the atomic rate limiter and the fenced-lease directory that arbitrates agent-session ownership across the mesh). A store that mishandled any of these would fail as a security or consistency bug, not an error message.

## Verification already done

I inventoried every command Buzz issues from source — including the commands inside all five Lua scripts — and replayed each with exact option shapes against a live Valkey 8.1.6 instance. Buzz's own Redis-dependent test suites (pub/sub covering presence + NIP-98 replay protection, the fenced-lease tunnel suite, and the mesh registry suite) then passed in full against that instance, including the client's `EVALSHA`→`SCRIPT LOAD` cache-fallback path.

Commands verified: `PUBLISH`, `SUBSCRIBE`, `PSUBSCRIBE`, `SET` (`EX`/`PX`/`NX`), `GET`, `MGET`, `DEL`, `INCR`, `EXPIRE`, `PEXPIRE`, `TTL`, `SCAN` (`MATCH`/`COUNT`), `PING`, `EVAL`/`EVALSHA`/`SCRIPT LOAD`. All 22 command/option combinations behaved identically. No Redis modules, streams, cluster APIs, or keyspace notifications are used anywhere in the codebase.

Because `redis-rs` connects to Valkey unmodified, this needs **zero application-code changes** — no client swap (no valkey-glide). The existing client is the right choice for a drop-in certification.

## Proposed scope (all additive, opt-in)

1. **Compose** — a Valkey service (`valkey/valkey:8-alpine`, `valkey-cli ping` healthcheck) gated behind a compose profile in the dev and self-host compose files, so `up` behaves exactly as before by default.
2. **Helm** — an optional Valkey subchart alongside the existing Redis one, plus documentation for pointing `externalRedis.url` at a managed Valkey endpoint (e.g. ElastiCache).
3. **Docs** — state that the connection string accepts any RESP-compatible endpoint including managed Valkey, with an ElastiCache example and a summary of the verification evidence.
4. **CI** — a scheduled/label-triggered lane running the existing backend-integration suite against a Valkey service instead of Redis, so it costs nothing on the PR path and converts the one-time verification into a continuously enforced guarantee.

The Redis default, the `REDIS_URL` variable name, and the client dependency all stay untouched — no existing deployment changes behavior.

**Out of scope:** any application-code, client-library, or default-backend change; Valkey Search/JSON/Streams. I mapped the other store-shaped abstractions in the codebase — they're backed by the Redis-compatible layer or by Postgres/Nostr events deliberately — so there's no differentiated-feature opportunity here, and none is proposed.

Would a PR along these lines be welcome? Happy to adjust the shape (e.g. profile naming, subchart source, CI trigger) to match your preferences before opening it.

Compare the dev compose file and deploy/compose/ bundle, then inspect the Helm Redis subchart and existing backend-integration CI lane. Add opt-in Valkey deployment support and documentation without changing Redis defaults, and verify completion by running the existing backend-integration suite against Valkey.

Written by the indexing model from the issue text.