feat: add api-log demo set (jpa + mybatis + r2dbc) with PostgreSQL Testcontainers IT

[jlc488]

Summary

Three new demos covering every persistence backend of the api-log starter so readers can pick the one matching their stack and `./gradlew bootRun` immediately.

Demo	Stack	API path	Backend writer
`api-log-jpa-demo`	Spring MVC + JPA + Postgres	blocking (`RestApiClientUtil`)	`JpaApiLogWriter`
`api-log-mybatis-demo`	Spring MVC + MyBatis + Postgres	blocking (`RestApiClientUtil`)	`MybatisApiLogWriter`
`api-log-r2dbc-demo`	WebFlux + R2DBC + Postgres	reactive (`ReactiveApiClientUtil`)	`R2dbcApiLogWriter`

Common design — self-loopback

The same app exposes both ends, so no external service is needed:

GET  /upstream/widgets/{id}              <- fake "service being called"
                                             (id=999 → 5xx, error path)
GET  /client/widgets/{id}                <- calls upstream via the
                                             api-log HTTP client util,
                                             returns the Widget;
                                             side-effect: api_log rows
POST /client/widgets/with-request-id/{id} <- explicit requestId via the
                                             core send(HttpMethod, ApiRequest)
                                             overload — retry correlation
GET  /api-log/recent                     <- table reader, top 20 by
                                             timestamp DESC
GET  /api-log/by-request/{requestId}     <- lifecycle of one call:
                                             INITIATED → SUCCESS / ERROR
GET  /api-log/by-event/{eventType}       <- filter by event type

Reader can curl the whole flow without leaving the demo:
```bash
docker compose up -d db
./gradlew bootRun
curl localhost:8080/client/widgets/123 # → Widget JSON
curl localhost:8080/api-log/recent # → INITIATED + SUCCESS pair
curl localhost:8080/client/widgets/999 # → 5xx
curl localhost:8080/api-log/recent # → also INITIATED + ERROR
```

Tests — Testcontainers + @Serviceconnection

Each demo ships `ApiLogLifecycleIT` (5 tests × 3 demos = 15 IT tests total):

1. happy GET path — INITIATED + SUCCESS pair lands in api_log
2. error path (id=999) — INITIATED + ERROR pair lands
3. POST body preserved — `api_log.payload` JSONB contains the widget fields
4. explicit requestId correlation — `/api-log/by-request/demo-fixed-rid` returns the lifecycle entries
5. schema initialized on boot — table query doesn't throw

Each IT spins up `postgres:16-alpine` via Testcontainers, makes real HTTP self-loopback calls (so the api-log event listener actually fires), and uses Awaitility to poll past the async write window.

CI auto-detects new demos by the presence of `build.gradle.kts` — no workflow edits required.

Backend-specific notes

JPA (`api-log-jpa-demo`):

• Reader uses the starter's published `ApiLogRepository extends JpaRepository<ApiLogEntity, Long>`
• `spring.jpa.hibernate.ddl-auto=none` — api-log's own `ApiLogJpaSchemaInitializer` creates the table (`api.log.schema.management=BUILTIN`)

MyBatis (`api-log-mybatis-demo`):

• Bundled `ApiLogMapper.findByRequestId` for by-request lookups, plus a custom `ApiLogQueryMapper` (xml) for `findRecent` / `findByEvent` that the starter doesn't expose
• `@MapperScan` scoped to the demo package only — scanning the starter's package would double-register its internal mapper

R2DBC (`api-log-r2dbc-demo`):

• Reader uses `DatabaseClient` directly (no Spring Data R2DBC repository — the r2dbc backend doesn't ship one)
• JSONB columns cast to `::text` in the SELECT so they bind to a public `ApiLogView` record's `String` fields
• Schema initializer is opt-in via `api.log.r2dbc.schema.enabled=true` (different property from the JDBC backends — per `ApiLogProperties` javadoc)
• Both `r2dbc-postgresql` and `postgresql` (JDBC) drivers — JDBC is what Testcontainers' `@ServiceConnection` prefers for rewiring

Test plan

• CI matrix builds all 3 new demos
• Locally: `cd api-log-jpa-demo && docker compose up -d db && ./gradlew bootRun`, then curl through the loopback flow
• Same for `api-log-mybatis-demo` and `api-log-r2dbc-demo`
• `./gradlew test` in each demo (Testcontainers spins up its own ephemeral Postgres)

Sibling work in flight

PR #61 adds two more ssrf-guard demos (httpclient5 + native-image) on a parallel branch. The two PRs touch different directories so they're independent in scope — but `README.md` will conflict on the table ordering after the second one lands. Whichever merges second rebases.

Maven Central artifact verification

All four api-log 3.0.0 jars verified on Maven Central before this PR was raised:

• `kr.devslab:api-log-core:3.0.0` ✅
• `kr.devslab:api-log-jpa:3.0.0` ✅
• `kr.devslab:api-log-mybatis:3.0.0` ✅
• `kr.devslab:api-log-r2dbc:3.0.0` ✅