docs(d4): measure the controls before the injection that needs a password

The forced renewal needs sudo on the host, and the host asks for a password.
That blocks the injection, not the experiment — the part worth doing first
was the control anyway.

Control 1 — new connections, 0.2s x 900 over 180s: 900/900 = 200, zero
failures. The noise floor is 0, so a single non-200 during the renewal can
be attributed to the renewal. Without this the observation would have been
uninterpretable, which is the mistake A-6 made calling a -41% control
"no effect" and A-8 made claiming zero-downtime from 9 samples.

Control 2 — the poll cannot answer the question the plan actually asked.
TLS handshakes were 900/900, meaning every request is a fresh connection,
so it measures "are new connections accepted", not "what happens to a
request already in flight". A separate device: the 845KB admin console
bundle pulled at --limit-rate 20k, holding one request open for 42 seconds.
Baseline 200 / 845361 bytes / 1 connection.

Monitors are running under setsid, and stop three minutes after the
certificate serial changes.

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

docs/evidence/d4-certificate-renewal/05-control-no-injection.txt

@@ -0,0 +1,19 @@
+D-4 대조군 — 주입 없는 상태의 가용성 잡음 바닥
+수집 시각(dev): 2026-09-04T08:03:07Z UTC
+대상: https://auth.hyeonworks.com/realms/master  ·  0.2초 간격 900회 = 180초
+형식: http_code time_total time_appconnect(TLS 핸드셰이크까지)
+왜: 갱신 중 000 이 한 번 나와도, 평시 오류율을 모르면 그게 갱신 탓인지 알 수 없다.
+----------------------------------------------------------------
+표본 900 개
+
+[상태코드 분포]
+      900 200
+
+[응답시간 ms]
+  최소 67  중앙 98  p95 195  최대 1121  평균 106.9
+
+[TLS 핸드셰이크 ms — 0 이면 연결 재사용, >0 이면 새 핸드셰이크]
+  핸드셰이크 발생 900회 / 900  평균 83 ms  최대 1100 ms
+
+[비정상 응답 원문 — 있으면 아래에 전부]
+  비200 총 0

docs/evidence/d4-certificate-renewal/06-inflight-control.txt

@@ -0,0 +1,22 @@
+D-4 대조군 2 — '진행 중이던 요청' 측정 장치의 무주입 동작
+수집 시각(dev): 2026-09-04T08:08:45Z UTC
+
+왜 이 장치가 따로 필요한가
+  05-control 의 0.2초 폴링은 매 요청이 새 TCP 연결이다(핸드셰이크 900/900).
+  그래서 '새 연결을 받아주는가'는 재지만, D-4 가 묻는 '이미 진행 중이던
+  요청이 어떻게 되는가'는 재지 못한다. 재하려면 reload 순간에 실제로
+  전송 중인 요청이 있어야 한다.
+
+장치
+  845KB 짜리 관리 콘솔 번들을 --limit-rate 20k 로 내려받는다.
+  응답을 일부러 느리게 읽어 요청을 ~42초 동안 살아 있게 만든다.
+  대상: https://auth.hyeonworks.com/resources/55yjq/admin/keycloak.v2/assets/main-BbID33M6.js
+----------------------------------------------------------------
+[대조군: 주입 없이 1회]
+  코드=200  받은바이트=845361  총시간=41.392198s  연결수=1  실효속도=20423B/s
+  기대 크기 845361 / 실제 845361 bytes
+
+판정 기준 (주입 시 이 값들과 비교한다)
+  · 코드 200 + 크기 845361 = 진행 중이던 요청이 끝까지 살아남았다(graceful)
+  · 코드 000 또는 크기 부족  = reload 가 진행 중이던 연결을 끊었다
+  · 연결수 2 이상            = 중간에 끊겨 curl 이 다시 붙었다

docs/evidence/d4-certificate-renewal/README.md

@@ -6,9 +6,13 @@
 | 파일 | 무엇을 보여주는가 |
 |---|---|
 | `01-certificate-state.txt` | SAN 3개(와일드카드 아님) · **체인 4단계, `Verify return code: 0`** · `certbot-renew.timer` enabled·active, 11시간 전 실행 · 88일 남음 · **`sudo: a password is required` 로 강제 갱신 불가** |
+| `05-control-no-injection.txt` | **대조군 1 — 잡음 바닥.** 0.2초 × 900회 / 180초 동안 **900전부 200, 오류 0**. 중앙 98ms · p95 195ms. **TLS 핸드셰이크 900/900** = 매 요청이 새 연결이다 |
+| `06-inflight-control.txt` | **대조군 2 — '진행 중이던 요청' 측정 장치.** 845KB 번들을 `--limit-rate 20k` 로 받아 요청을 **42초간 살려 둔다.** 무주입 시 코드 200 · 845361바이트 · 연결수 1 |
 
 ## 핵심 세 줄
 
 1. **인증서가 이름 3개만 담는다.** B-7 에서 oauth2-proxy 를 올릴 호스트가 없어 Grafana 의 `app2` 를 빌려야 했던 실제 비용이 여기서 나왔다.
 2. **체인이 완전하다** — 단계가 4개이므로 `fullchain.pem` 을 쓰고 있다. 1개면 `cert.pem` 실수이며 캐시 없는 클라이언트에서만 깨진다.
-3. **강제 갱신은 못 했다.** 호스트 sudo 가 비밀번호를 요구한다. 타이머가 active 라는 것은 "갱신이 된다"의 확인이 아니다.
+3. **강제 갱신은 아직 못 했다.** 호스트 sudo 가 비밀번호를 요구한다. 타이머가 active 라는 것은 "갱신이 된다"의 확인이 아니다.
+4. **주입 전에 대조군을 먼저 잡았다.** 평시 실패가 0/900 이므로, 갱신 중 비200 이 한 번이라도 나오면 갱신 탓으로 귀속할 수 있다. 대조군 없이 주입부터 했다면 그 한 번을 해석할 수 없었다 — A-6 에서 −41% 를 "영향 없음"이라 적었던 실수가 바로 그것이다.
+5. **폴링만으로는 D-4 의 질문에 답할 수 없다.** 핸드셰이크 900/900 이 말해주듯 매 요청이 새 연결이라, 재는 것은 "새 연결을 받아주는가" 뿐이다. 계획서가 물은 "진행 중이던 요청"은 42초짜리 in-flight 장치로 따로 잡는다.