chore: record pre-existing uncommitted repository state

Snapshot of the in-flight state that already existed, identically, in both
this worktree and the main checkout before this session began: the initial
HTTP Client platform implementation (previously untracked), the redis-lab
removal, and the JPA / object-storage / notification integration work.

Kept separate from this session's HTTP Client review response, which lands
in the following commit, so the two bodies of work stay reviewable apart.

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

infra/redis-sdk/tls/compose.yml

@@ -0,0 +1,78 @@
+# TLS lane for the Redis SDK topology tests.
+#
+# Standalone in shape, but the point is the transport: the SDK's TLS settings — enabled, hostname
+# verification, trust material, client certificate — are configuration nothing else exercises, and
+# a TLS path that has never carried a command is a claim rather than a capability.
+#
+# The certificates are generated at start-up rather than checked in. A checked-in key is a secret in
+# the repository however loudly the file is named "test", and a lane that regenerates its own
+# material also proves the trust configuration actually matters: point the client at the wrong CA
+# and it fails, which is what the qualification has to show.
+services:
+  certs:
+    # The redis image carries no openssl, so certificate generation gets an image that does. The
+    # alternative — checking the material in — puts a private key in the repository.
+    image: alpine/openssl:latest
+    user: root
+    volumes:
+      - tls:/tls
+    entrypoint:
+      - /bin/sh
+      - -c
+      - |
+        set -e
+        if [ -f /tls/redis.crt ]; then exit 0; fi
+        openssl genrsa -out /tls/ca.key 2048
+        openssl req -x509 -new -nodes -key /tls/ca.key -sha256 -days 1 \
+          -subj "/CN=ca-skeleton-test-ca" -out /tls/ca.crt
+        openssl genrsa -out /tls/redis.key 2048
+        openssl req -new -key /tls/redis.key -subj "/CN=localhost" -out /tls/redis.csr
+        printf 'subjectAltName=DNS:localhost,IP:127.0.0.1' > /tls/redis.ext
+        openssl x509 -req -in /tls/redis.csr -CA /tls/ca.crt -CAkey /tls/ca.key \
+          -CAcreateserial -out /tls/redis.crt -days 1 -sha256 -extfile /tls/redis.ext
+        chmod 644 /tls/redis.key /tls/ca.key
+
+  redis:
+    image: "redis:${REDIS_VERSION:-7.4}"
+    depends_on:
+      certs:
+        condition: service_completed_successfully
+    volumes:
+      - ../acl:/etc/redis/acl:ro
+      - tls:/tls:ro
+    command:
+      - redis-server
+      # Plaintext is off entirely. A lane that accepts both proves nothing about the TLS path,
+      # because a misconfigured client would quietly fall back and still pass.
+      - --port
+      - "0"
+      - --tls-port
+      - "6379"
+      - --tls-cert-file
+      - /tls/redis.crt
+      - --tls-key-file
+      - /tls/redis.key
+      - --tls-ca-cert-file
+      - /tls/ca.crt
+      - --tls-auth-clients
+      - "no"
+      - --appendonly
+      - "no"
+      - --save
+      - ""
+      - --aclfile
+      - /etc/redis/acl/all-accounts.acl
+    ports:
+      - "${REDIS_PORT:-6390}:6379"
+    healthcheck:
+      test:
+        - CMD-SHELL
+        - >-
+          [ "$$(redis-cli --tls --cacert /tls/ca.crt
+          --user ca-skeleton-application --pass fixture-application --no-auth-warning ping)" = PONG ]
+      interval: 2s
+      timeout: 3s
+      retries: 20
+
+volumes:
+  tls: