docs: B-0 — deploy the BFF and read what autoconfiguration actually chose

The authorized client repository is AuthenticatedPrincipalOAuth2AuthorizedClientRepository, keyed by principal with no session id in it, which is the mechanism behind the sharing problem Q1 and Q3 describe. Sharing a store does not fix a lookup key.

Five problems on the way in: only build output was committed under bff/, a duplicate YAML key broke the image build and was invisible until the full log was captured, env placeholders without defaults broke the tests, actuator was behind the login redirect so a 200 was the login page, and the 117KB beans response failed through the proxy.

Deploying two replicas made the login itself fail before any experiment started, because the authorization request lives in per-instance memory and the callback lands elsewhere.

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

docs/evidence/b0-bff-redis-deploy/01-deploy.txt

@@ -0,0 +1,21 @@
+=== 배포 전 자원 ===
+Mem:           11648        7329         280           4        4377        4319
+NAME       CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)   
+kc-lab-1   115m         5%       2192Mi          44%         
+kc-lab-2   121m         6%       1324Mi          33%         
+
+=== 배포 ===
+secret/bff-secrets created
+deployment.apps/redis created
+service/redis created
+deployment.apps/bff created
+service/bff created
+ingress.networking.k8s.io/bff created
+
+deployment "redis" successfully rolled out
+Waiting for deployment "bff" rollout to finish: 1 of 2 updated replicas are available...
+deployment "bff" successfully rolled out
+
+bff-574c6d658b-8cz4x        true   kc-lab-1
+bff-574c6d658b-zpkbp        true   kc-lab-2
+redis-568bd7c4-5c5vc        true   kc-lab-2