fix(ssot): 기록에만 있던 2026-09-17 실측 넷을 SSOT 에도 넣는다

기록과 SSOT 를 대조해 한쪽에만 들어간 실측을 찾았다. 넷이 기록에만 있었다.

- A-0 시험 0c 의 `9 + 5 = 14` 와 DB 총계 대조
- A-8 의 `created_on` 은 그대로이고 `last_session_refresh` 만 117초 뒤로 간 것
- 토큰 길이가 판마다 다르다는 것 (`612자`·`758자` 대 `1187자`·`2043자`)

나머지 실측은 양쪽에 다 들어가 있는 것을 확인했다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/keycloak-session-store/final/document.md

@@ -606,6 +606,22 @@ COMMIT 이 WAL 디스크 기록을 기다리지 않고 즉시 반환한다. 그
 
 `persistent-user-sessions` 를 켜는 진짜 이유가 여기에 있다.
 
+**★ 2026-09-17 에 다시 쟀다**(observed). 세션 수 대신 **행의 두 시각**을 견줘서 같은
+것을 더 좁게 보였다.
+
+```
+재시작 전 대조군            200
+재시작 (파드 둘 교체)       AGE 31s · 63s · IP 10.42.1.47→.49, 10.42.0.20→.21
+재시작 뒤 같은 refresh      200 · session_state 가 같은 sid
+DB 행                       created_on 1789625835 그대로
+                            last_session_refresh 1789625835 → 1789625952
+캐시                        재시작 전후 모두 sessions 0
+```
+
+**`created_on` 은 안 바뀌고 `last_session_refresh` 만 117초 뒤로 갔다.** 새로 만든
+세션이 아니라 **남아 있던 행을 새 파드가 읽어서 갱신한 것**이고, 「세션은 살아남고
+캐시만 사라진다」의 가장 좁은 증거다.
+
 ![재시작이 지우는 것과 남기는 것](assets/a8-cache-vs-session/a8-cache-vs-session.svg)
 
 캐시와 세션을 분리하지 않으면 재시작 후 로그인이 유지되는 이유를 설명할 수 없다.
@@ -5129,7 +5145,13 @@ AT=$(echo "$R" | sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p')
 echo "refresh=${#RT}자 access=${#AT}자"
 ```
 
-`refresh=1187자 access=2043자` 같은 모양이 나온다. 길이가 `0자` 면 로그인이
+`refresh=1187자 access=2043자` 같은 모양이 나온다.
+
+**★ 그 두 수를 기준값으로 삼지 않는다.** 2026-09-17 에 다시 세운 실험대에서는
+`refresh=612자 access=758자` 였다(observed). 담긴 클레임과 서명 길이에 따라 달라지므로
+**보는 것은 `0자` 가 아니라는 것 하나**다.
+
+길이가 `0자` 면 로그인이
 실패한 것이고 `echo "$R"` 로 에러 본문을 본다.
 
 JWT 의 가운데 토막이 클레임이다. 가이드는 **먼저 통째로 디코드해 눈으로 보고**
@@ -5358,6 +5380,20 @@ keycloak-0 에 로그인 5회             7.0          5.0
 대각선이다. **한 번에 한 쪽만 는다.** 그리고 **7 + 5 = 12** 로 DB 총계와 정확히
 맞으므로 어느 엔트리도 두 번 세어지지 않았다.
 
+**★ 2026-09-17 에 같은 모양이 다시 나왔다**(observed). 로그인 수만 달라 숫자가 다르다.
+
+```
+단계                         k0 entries   k1 entries
+시작                              4            0
+keycloak-1 에 로그인 5회          4            5
+keycloak-0 에 로그인 5회          9            5
+
+대조: PostgreSQL 의 online 세션   14      ← 9 + 5 = 14
+```
+
+캐시 합계와 DB 총계가 맞으므로 어느 엔트리도 두 번 세어지지 않았다. **판정에 쓰는 것은
+숫자가 아니라 「한 번에 한 쪽만 늘고, 두 캐시의 합이 DB 총계와 같다」 두 가지다.**
+
 ```bash
 kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
   -c "select count(*) from offline_user_session where offline_flag='0'"

docs/keycloak-session-store/tech-log-studio/tech-log-tree.json

@@ -7,7 +7,7 @@
     "revision": "9465582b5d1630eb4ae7c4e078021486919bf6b6",
     "verified": "반입할 때 적어 둔 source/.source-revision 이 이 커밋이고 저장소에 실재한다 — 「chore: 실행 환경 구성 문서 추가 및 수정」, 2026-09-10. **전에 이 칸은 cdac9b81 이었고 그것은 틀렸다** (2026-09-17 대조) — 그 커밋은 2026-09-04 이고 반입본 306개 가운데 docs/guides/** 28개가 거기에 아예 없다. 가이드는 그 엿새 뒤 6f6ab86 에서 들어왔다. **그런데 반입한 바이트는 이 커밋과도 같지 않다** — 9465582b 와 같은 것은 276개이고 29개가 다르다. 같은 306개를 저장소의 **작업 트리**와 견주면 297개가 같다. HEAD 에서 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 6f6ab86 도 28개가 어긋났다. **맞는 커밋은 없다** — 반입은 커밋이 아니라 **그 시점의 작업 트리**(미커밋 수정이 있던 상태)에서 떠 온 것이다. 지금도 저장소는 그 파일들을 M 으로 낸다. 작업 트리와 남은 차이 8개 가운데 5개가 그 M 목록에 있고(반입 뒤 저장소가 더 고쳤다), deploy/lab/host/nginx-keycloak-lab.conf 는 저장소에서 deploy/lab/edge/ 로 옮겨져 반입본에만 남았다. **이 커밋은 「반입 시점의 HEAD」라는 뜻이지 「반입한 바이트가 이것이다」가 아니다**"
   },
-  "ssotSha256": "f3916ea7c24798627a7e75e5f859af25e29ff404d218816c032e9356f0bf9dc8",
+  "ssotSha256": "23a3efedf685f954fd69d6c90f1468e258457f7dd61142ef7652c8e8c6fa27e0",
   "sourceRevision": "keycloak-session-lab@2026-09",
   "generatedAt": "2026-09-17",
   "candidateScope": {