docs: capture the SQL the other node actually runs, and correct the replication claim

PostgreSQL statement logging shows keycloak-1 reading and updating the session created on keycloak-0. The same transaction reveals optimistic locking via VERSION, SKIP LOCKED, and synchronous_commit turned off. Fixes the earlier concept note that credited Infinispan with cross-node propagation.

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

docs/session-lab-concepts.md

@@ -3141,18 +3141,39 @@ kubectl -n keycloak-lab logs keycloak-0 | grep -E 'ISPN000094|ISPN000079|ISPN100
 suspect 하고, GMS가 그 멤버를 뷰에서 제외한다. 각자 자기만 있는 뷰가 되면
 **split brain**이고, 통신이 복구되면 MERGE3가 합친다.
 
-### 세션은 어디에 있는가 — 두 곳 다
+### 세션은 어디에 있는가 — 두 곳이되 역할이 다르다
 
 Keycloak 26의 기본값 `persistent-user-sessions`에서는
 
-| 저장소 | 역할 |
-|---|---|
-| **PostgreSQL** | **진실의 원천.** 재시작에도 살아남는다 |
-| **Infinispan** | 캐시 + 노드 간 실시간 전파 |
+| 저장소 | 역할 | 노드 간 공유 |
+|---|---|---|
+| **PostgreSQL** | **진실의 원천.** 재시작에도 살아남는다 | **여기서만 일어난다** |
+| **Infinispan `sessions`** | **자기 노드가 로그인시킨 세션만** 담는 룩어사이드 캐시 | **일어나지 않는다** |
+
+> **처음에 이 표에 "Infinispan = 캐시 + 노드 간 실시간 전파"라고 썼는데
+> 틀렸다.** 실험 0에서 측정해보니 세션 엔트리는 노드 사이를 건너가지 않는다.
+> 두 노드가 같은 답을 하는 이유는 복제가 아니라 같은 DB를 보기 때문이고,
+> 반대편 노드가 실제로 날리는 `SELECT ... FROM OFFLINE_USER_SESSION` 을
+> PostgreSQL 로그에서 직접 잡았다.
+> → [`docs/experiment-00-session-replication.md`](experiment-00-session-replication.md)
 
 `--features-disabled=persistent-user-sessions`로 끄면 Infinispan만 남는
-**volatile** 모드가 되고, 그때는 캐시가 곧 진실의 원천이다.
-이 둘의 차이가 로드맵 2번의 주제다.
+**volatile** 모드가 되고, 그때는 캐시가 곧 진실의 원천이므로 **복제가
+반드시 일어나야 한다.** 이 둘의 차이가 로드맵 2번의 주제다.
+
+### 세션 쓰기 트랜잭션의 세 가지 설계 결정
+
+PostgreSQL 문장 로깅으로 잡은 갱신 트랜잭션 하나에 다 들어 있다.
+
+| 보이는 것 | 뜻 |
+|---|---|
+| `update ... where ... and VERSION=$5` | **낙관적 락.** 읽을 때의 버전과 같을 때만 쓴다 |
+| `for no key update ... skip locked` | 잠긴 행을 **기다리지 않고 건너뛴다.** 대기 대신 재시도 |
+| **`SET LOCAL synchronous_commit TO OFF`** | **WAL 플러시를 기다리지 않고 커밋한다** |
+
+마지막 것이 특히 중요하다 — **DB가 강제 종료되면 직전 수백 밀리초의 세션
+갱신이 사라질 수 있다.** 버그가 아니라 의도된 트레이드오프다.
+`LAST_SESSION_REFRESH` 갱신은 매우 잦고, 잃어도 사용자가 다시 갱신하면 된다.
 
 ---