docs(a7a): the volatile refresh failure is a client-scope lookup, not REVOKED_TOKEN

A-7 left the cause as a hypothesis and said to confirm it with the statement
logging A-3 used. Doing that shows the hypothesis was wrong.

Login issues no SQL at all in volatile mode. Refresh issues exactly one
statement, and it is not the one A-7 guessed:

  select cscme1_0.SCOPE_ID from CLIENT_SCOPE_CLIENT cscme1_0
   where cscme1_0.CLIENT_ID=$1 and cscme1_0.DEFAULT_SCOPE=$2
   parameters: $1 = '131a9912-...', $2 = 'f'

REVOKED_TOKEN never appears. DEFAULT_SCOPE='f' means this is the optional
client scope list, which refresh needs because it recomputes which scopes go
into the new access token.

The larger finding is that A-7's table was conditional and did not say so.
The single statement is issued once and then cached, so the same
configuration produces three different outcomes depending only on cache
warmth — all three reproduced:

  fully cold      login 400  (select ce1_0.ID from CLIENT ...)
  CLIENT warm     login 200, refresh 500  <- what A-7 measured
  fully warm      login 200, refresh 200

So "volatile means you can log in without a database" is also conditional:
on a cold start the client lookup itself fails. In each case the Keycloak
log names the failing SQL directly, so this is determined rather than
inferred.

A-7 keeps its original wording with a correction banner above it, so what
was mis-guessed and why stays visible.

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

docs/experiment-a7-volatile-comparison.md

@@ -29,6 +29,11 @@
 
 **세 개가 정반대로 뒤집혔다.** 예측한 그대로다.
 
+> **★ 이 표에는 조건이 빠져 있다 (A-7a).** volatile 행의 A-2 결과는
+> **캐시 온도에 따라 달라진다.** 완전 냉시동이면 로그인도 `400` 이고,
+> 캐시가 완전히 더우면 refresh 도 `200` 이다. 여기 적힌 값은 그 사이의
+> 한 상태다 — 셋 다 [A-7a](experiment-a7a-volatile-cause.md) 에서 재현했다.
+
 > **"세션 공유는 7800 을 안 탄다"는 A-1 의 결론은 버전에 달린 사실이다.**
 > 인터넷 자료 대부분이 24 이전 기준이므로 **거기서는 통념이 맞다.**
 > 틀린 것은 자료가 아니라 **버전을 확인하지 않고 적용하는 것**이다.
@@ -164,6 +169,13 @@ partitioned roll out complete: 2 new pods have been updated...
 
 ### refresh 가 500 인 이유 — 가설
 
+> **★ 정정 (A-7a)** — 이 가설은 **틀렸다.** 문장 로깅으로 확정한 결과
+> 원인은 `REVOKED_TOKEN` 이 아니라 **`CLIENT_SCOPE_CLIENT` 조회**였다.
+> 더 중요하게는 **위 표 자체가 캐시 온도에 따라 400/500/200 으로 갈린다.**
+> [A-7a 문서](experiment-a7a-volatile-cause.md) 참조.
+
+아래는 정정 전 원문이다 — 무엇을 어떻게 잘못 짚었는지 남긴다.
+
 **측정은 확실하지만 원인은 확정하지 못했다.** 유력한 후보는
 `REVOKED_TOKEN` 테이블이다 — refresh token 회전에서 **이미 쓴 토큰인지**
 확인하려면 그 테이블을 봐야 하고, 그 경로는 캐시되지 않는다.
@@ -174,7 +186,7 @@ kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c
 ```
 
 **확정하려면 A-3 에서 쓴 문장 로깅을 켜고 다시 재현해야 한다.** 여기서는
-**가설로 남긴다.**
+**가설로 남긴다.** → **A-7a 에서 그대로 실행해 확정했고, 가설은 틀렸다.**
 
 > **volatile 이 "DB 없이 돌아간다"는 뜻은 아니다.**
 > realm·사용자·클라이언트·취소 토큰은 **여전히 DB 에 있다.**