Sync the self-hosting stack

kubernetes/08-redis-sentinel.yaml

@@ -10,11 +10,19 @@
 # somebody else to hold that, use a managed Redis or an operator. What this directory owes you is
 # the shape the application needs, and this is it.
 #
-# The application half is proven rather than assumed: an ioredis client built exactly the way
-# `apps/api/src/redis/redis-connection.ts` builds one was run against a live three-sentinel
-# topology while its primary was killed. It followed the promotion to a different server, and 99
-# writes issued across the window were rejected zero times. What it does NOT do is preserve pub/sub
-# during the switch — see "What a failover actually costs" at the bottom.
+# The application half is proven rather than assumed, though not all of it on the api that ships
+# now. On the TypeScript api, an ioredis client built exactly the way its `redis-connection.ts`
+# built one was run against a live three-sentinel topology while its primary was killed. It
+# followed the promotion to a different server, and 99 writes issued across the window were
+# rejected zero times. What it does NOT do is preserve pub/sub during the switch — see the failover
+# section of the README beside this file.
+#
+# The .NET api reaches Redis through StackExchange.Redis, asking these sentinels for the primary
+# (src/Jarvis.Api/Infrastructure/RedisConnection.cs). Proven for it, on a throwaway cluster synced
+# from these manifests with 02-config.yaml's two REDIS_SENTINEL* lines: every pod wrote to the
+# primary — its leases taken, the console's realtime socket open, no READONLY refusal — where
+# REDIS_URL alone, on the headless Service below, landed writes on a read-only replica. Its
+# failover has NOT been measured: that it follows a promotion as ioredis did is not known.
 #
 #   kubectl apply -f 08-redis-sentinel.yaml
 #