docs(keycloak-session-store): import the session-storage lab as a new project

The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.

Follows the import procedure in README.md.

  source/     the originating repository verbatim — 78 documents, 28 SVGs,
              8 manifests, plus .source-revision recording the commit
  final/      the SSOT
    document.md   729 lines written from the 29 experiment documents, not
                  concatenated: what was predicted, what was measured, and
                  where the measurement itself was wrong
    evidence/raw    125 outputs, flattened to <experiment>__<file> because
                    the originals collided (01-baseline.txt appeared three
                    times) and the audit only globs the top level
    evidence/meta   one per raw file; command and exitCode are null and the
                    README says why rather than inventing them
    evidence/browser  22 captures
    assets/       three diagrams through techviz
    .techviz/     their VizSpecs

A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.

Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.

verify-pipeline.py passes. audit-records.py reports no issues.

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

docs/clean-architecture-backend-template/tech-log-studio/declaration-and-document-drift/question/openquestion-messaging-inbox-jdbc-postgresql-f04.md

@@ -0,0 +1,50 @@
+---
+kind: QUESTION
+slug: messaging-inbox-jdbc-postgresql-f04
+title: 세 갈래 판정이 포트의 boolean에서 두 갈래로 접힌다
+topic: declaration-and-document-drift
+project: clean-architecture-backend-template
+status: 게시 전
+sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
+rootTreeNode: open-question:messaging-inbox-jdbc-postgresql-f04
+questionStatus: OPEN
+verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
+source:
+  - analysis/messaging/messaging-inbox-jdbc-postgresql.md#L675
+---
+
+# 세 갈래 판정이 포트의 boolean에서 두 갈래로 접힌다
+
+같은 `false` 가 "이미 처리됐다" 와 "다른 인스턴스가 처리 중이다" 를 함께 뜻한다. 후자가 실제로 도달 가능한 상태인지에 따라 이것이 결함인지 과설계인지가 갈린다.
+
+## 관계
+
+- **컬럼 폭은 애플리케이션 검증과 짝을 이룬다**
+  같은 분석 리프에서 끌어낸 규칙이다.
+- **같은 안전 규칙은 한 공식과 한 강제 시점을 갖는다**
+  같은 분석 리프에서 끌어낸 규칙이다.
+
+## 사실
+
+InboxResult 가 세 값과 isSafeToSettle() 을 갖는데 production 은 APPLIED 만 만든다.
+
+InboxRepository.reserve 가 boolean 을 반환하므로 ALREADY_APPLIED 와 CLAIMED_ELSEWHERE 가 같은 false 로 들어온다. TransactionalInboxHandler 는 그 경우 HandleResult.success() 를 반환한다 — 정산한다.
+
+InboxResult javadoc 이 세 값이 필요한 이유로 정확히 그 정산을 든다 — "would settle a message whose effect is still only half-written by another instance".
+
+## 미지수
+
+ON CONFLICT DO NOTHING 이 미커밋 충돌에 대해 대기하는가 즉시 0을 반환하는가. 대기하면 CLAIMED_ELSEWHERE 는 도달 불가능한 상태이고 enum 이 과설계인 것이며, 즉시 0을 반환하면 이것은 실제 결함이다.
+
+## 선택지
+
+포트 반환 타입을 InboxResult 로 바꾼다
+   세 갈래가 호출자까지 도달하고 정산 판단이 갈린다. 확인 결과 발생 가능할 때의 선택이다.
+
+현 형태를 유지하고 도달 불가임을 적는다
+   대기가 확인되면 enum 의 세 번째 값이 왜 남아 있는지가 기록돼야 한다.
+
+## 다음 검증
+
+두 커넥션에서 같은 (message, consumer) 를 예약하고 한쪽을 커밋하지 않은 채 다른 쪽의 executeUpdate() 반환을 관측한다. InboxPostgresIT 에 추가 가능하다.
+