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/retention-and-unbounded-growth/concept/concept-bounded-and-unbounded-side-by-side.md

@@ -0,0 +1,91 @@
+---
+kind: CONCEPT
+slug: bounded-and-unbounded-side-by-side
+title: bounded 와 unbounded 오버로드를 나란히 둔 포트
+topic: retention-and-unbounded-growth
+project: clean-architecture-backend-template
+status: 게시 전
+sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
+rootTreeNode: concept:bounded-and-unbounded-side-by-side
+evidenceCapturedOn: 2026-09-01
+assets:
+  - key: bounded-and-unbounded-side-by-side
+    file: ../../../final/evidence/rendered/bounded-and-unbounded-side-by-side.svg
+  - key: bounded-and-unbounded-side-by-side-diagram
+    file: ../../../final/assets/diagrams/bounded-and-unbounded-side-by-side.svg
+evidence:
+  - ../../../final/evidence/raw/bounded-and-unbounded-side-by-side.txt
+source:
+  - 원본 분석 절은 analysis/messaging/messaging-reliability-api.md §17 · analysis/messaging/messaging-inbox-jdbc-postgresql.md §17 이다.
+---
+
+# bounded 와 unbounded 오버로드를 나란히 둔 포트
+
+두 포트가 각각 정리 연산의 무제한 형태와 배치 제한 형태를 오버로드로 나란히 선언한다. 두 형태를 가르는 표시가 없어서 호출자가 인자가 적은 쪽을 골랐다.
+
+## 관계
+
+- **두 형태를 나란히 내놓는 포트는 이미 안전하지 않은 쪽을 고른 것이다**
+  이 구조에서 나온 규칙이다.
+- **cleanup 이 스스로 막겠다고 적은 장애를 일으키는 형태로 호출된다**
+  이 구조가 실제로 발현한 사례다.
+- **같은 개념의 두 어휘가 공존하면 하나를 죽은 것으로 표시한다**
+  같은 계열의 기존 규칙이다.
+
+## 본문
+
+<!-- body:start -->
+
+두 포트가 각각 `purge*Before(Instant)` 와 `purge*Before(Instant, int)` 를 나란히 선언한다. 뒤쪽이 안전한 형태이고 그 이유가 javadoc 에 있다 — "The cleanup jobs describe themselves as bounded by batch size; this is the parameter that makes that true." 두 형태를 가르는 표시는 없다.
+
+## 두 오버로드를 가르는 표시
+
+:::evidence key="bounded-and-unbounded-side-by-side-diagram" alt="무제한 오버로드와 가르는 표시 없음이 왼쪽에, 배치 제한 오버로드와 javadoc 근거가 오른쪽에 같은 축으로 놓인다" caption="두 오버로드를 가르는 표시" zoom="false"
+:::
+
+## 호출자가 인자가 적은 쪽을 고른다
+
+`@Deprecated` 도, 이름 차이도, 호출을 막는 가시성 차이도 없다.
+
+## 두 오버로드의 javadoc
+
+:::evidence key="bounded-and-unbounded-side-by-side" alt="분석 문서 analysis/messaging/messaging-reliability-api.md 에서 이 기록의 근거 절을 그대로 잘라낸 18줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/messaging/messaging-reliability-api.md 발췌 — 18줄" zoom="true"
+:::
+
+## 결함이 호출자에게 있지 않다
+
+같은 리프가 다른 곳에서 같은 형태를 이미 기록했다 — 한 인터페이스가 같은 전이의 두 세대를 갖고 안전하지 않은 쪽에 표시가 없다. 포트의 형태가 오용을 가능하게 했고, 두 리프에서 같은 방향으로 발생했다.
+
+:::note
+
+없음 — 두 포트의 선언과 저장소 전역 호출 지점을 전수 확인했다
+
+:::
+
+## 두 형태
+
+정리 연산은 기준 시각 이전의 행을 지운다. 무제한 형태는 시각만 받고, 배치 제한 형태는 시각과 최대 건수를 받는다.
+
+두 형태의 차이는 SQL 에서 드러난다. 제한 형태는 건수 제한과 잠긴 행 건너뛰기를 함께 쓴다. 한 번에 지우는 양이 정해져 있으므로 락 보유 시간과 WAL 기록량이 백로그 크기와 무관해진다.
+
+## 안전한 쪽이 무엇을 참으로 만드는가
+
+배치 제한 오버로드의 javadoc 이 자기 존재 이유를 적는다.
+
+> The cleanup jobs describe themselves as bounded by batch size; this is the parameter that makes that true.
+
+정리 잡이 자신을 배치 크기로 제한된다고 서술하는데, 그것을 참으로 만드는 것이 바로 이 파라미터라는 뜻이다.
+
+## 표시가 없다
+
+두 형태를 가르는 것이 인자 개수뿐이다. 폐기 표시도, 이름 차이도, 호출을 막는 가시성 차이도 없다.
+
+그래서 호출자는 짧은 쪽을 고른다. 그것은 호출자의 부주의가 아니라 포트가 만든 기본값이다. 인자를 하나 더 넘기려면 그 값을 어디서 가져올지 정해야 하고, 그 결정을 미루는 것이 자연스러운 선택이 된다.
+
+## 같은 리프가 같은 형태를 이미 기록했다
+
+이 포트에는 같은 전이의 두 세대 메서드도 나란히 있다. 안전하지 않은 쪽에 폐기 표시가 없고, production 은 신세대만 쓰지만 그것을 강제하는 것은 없다.
+
+두 사례가 한 인터페이스 안에 있다는 점이 이 개념의 요지다. 포트의 형태가 오용을 가능하게 했고, 같은 방향으로 두 번 발생했다.
+
+<!-- body:end -->