refactor!: make Ogiri a Java-friendly, Maven-tested session library

[mosobande]

Purpose

Make Ogiri a small, Java-friendly session library that composes with Spring Security instead of shipping two authentication architectures. The implementation remains Kotlin internally; Java callers use ordinary constructors, getters, Principal and Spring Security interfaces without a Kotlin compiler.

Implemented

• Retire the v3 token entity/service/repository hierarchy, sub-token APIs, JDBC/Caffeine/Redis token-cache adapters, JavaScript SDK and React demo. Remove their implementation-specific tests, fixtures and obsolete support files while retaining v4 lifecycle, isolation, transport and concurrency contracts.
• Supply sign-in from a normal UserDetailsService and password encoder, without a hand-built AuthenticationManager. Derive the public sign-in route from endpoint configuration and load actual user authorities. Keep application-owned authorization and additional authentication providers intact.
• Enforce canonical selector/verifier credentials, minimum verifier entropy, bounded selector retries, proof-before-account checks, fixed previous-token grace, authoritative revocation and credential erasure. Share transport parsing across filters and endpoints. Preserve malformed-request, bad-credential and authentication-backend error distinctions.
• Keep CSRF enabled. In the starter-owned header chain, exempt only explicit Ogiri credentials and POST JSON sign-in at the configured route. Unrelated public writes and browser-simple sign-in submissions remain protected. Cookie mode and application-owned chains retain their CSRF policy. The earlier CodeQL CSRF finding was corrected, not suppressed.
• Use bounded ID-page/bulk cleanup, monotonic activity updates, expiry-checked atomic writes, unambiguous subject-lock keys and sequential lock-initialization/mutation transactions. Avoid nested connection checkout during admission and user-wide revocation; test a single-connection pool and rotation surviving unrelated consumer rollback. Skip unnecessary previous-digest hashing and no-op event allocation.
• Publish six aligned modules through standard Gradle component metadata and a BOM. Supply 15 binary/source/API-documentation JARs for the five code modules, six POMs and 28 source-generated Spring configuration properties. Replace hand-written dependency XML and stale metadata. Add minimal Java/Kotlin applications and a standalone Java Maven consumer.
• Move unchanged PostgreSQL SQL to META-INF/ogiri/schema-postgresql.sql. The dependency no longer claims an application's Flyway V4 version or auto-provisions its schema. Verify the SQL extracted from the built JAR against a PostgreSQL Maven consumer using Hibernate validate.
• Consolidate CI and gate publication on consumer verification. Update existing README, integration, security, database, contribution and publishing guidance rather than adding an audit-document archive.

Verification

Final delivery head: 219c12b39905cc960678d3a4d1a73ce60f258970.

Final PR Build and CodeQL analysis passed. The CodeQL alert gate reports no new alerts in code changed by this PR. No checks were bypassed or security alerts dismissed.

The source implementation was verified before its native commits were pushed in run 34063485027. Its downloaded JUnit XML reports show:

Verification	Tests	Failures/errors	Skipped
Main Gradle suite: H2, Redis, HTTP, Java/Kotlin and lifecycle contracts	59	0	0
JPA contracts rerun on PostgreSQL	9	0	0
Standalone Maven consumer on H2	2	0	0
Standalone Maven consumer on PostgreSQL with packaged SQL	2	0	0

These are matrix executions, not 72 distinct tests. All five Javadoc artifacts contain generated HTML; core metadata includes scalar and nested settings; the JPA artifact has no automatically discovered Flyway SQL. The final PR Build reruns consumer, PostgreSQL and artifact gates from a fresh checkout.

Reproduce the local consumer path:

./gradlew check publishToMavenLocal
mvn --batch-mode -f sample/sample-java/pom.xml verify

Compatibility and release boundaries

This is an unreleased, breaking v4 migration, not a v3 patch. Existing v3 credentials and sub-token semantics do not carry over; arrange migration and re-authentication. Keep applied database migrations. Users of an older unreleased v4 snapshot that already applied V4__create_ogiri_sessions.sql must retain that exact version/content in application history before upgrading. Do not mix old and new v4 nodes during a rolling deployment because subject-lock encoding changed.

Supported target: Java 17+, Spring Boot 3.5, servlet applications; H2 and PostgreSQL verified. The default identity adapter assumes one realm and immutable usernames. Tenant, mutable-login and opaque-account-ID applications provide explicit subject/status/authority resolvers. Registration, account recovery, MFA and OAuth/OIDC remain application or identity-provider responsibilities.

This PR does not merge itself, create a release tag, validate Central/signing credentials, or publish to Maven Central. Release dependency analysis, signing and publication remain release gates. No production throughput percentage, MySQL/Boot 4 compatibility claim, full penetration-test claim or security certification is made. Temporary execution workflows are not part of this PR's final tree.