feat(tenant): TenantService + DB-backed tenant CRUD (planning §6.7)

[jlc488]

Summary

Phase A2 of the admin console plan. Closes the long-standing TenantService gap so the admin-ui Tenants page has something to call.

Stacked on #11.

tenant-api

• TenantMetadata record — id + name + mode + active + createdAt
• TenantService interface — create / rename / activate / deactivate / delete / findById / findAll

tenant-core

• PlatformTenantEntity — id varchar(64) PK (= TenantId slug, not UUID; keeps existing string-based tenant_id columns working without FK churn)
• JpaPlatformTenantRepository
• DefaultTenantService implementation
• new deps: spring-boot-starter-data-jpa, Lombok (compileOnly)
• db/migration/V7__platform_tenant.sql

autoconfigure

• TenantAutoConfiguration grows a @ConditionalOnBean(JpaPlatformTenantRepository.class) + @ConditionalOnMissingBean TenantService bean. Apps without JPA still get TenantContextHolder + TenantResolver but no TenantService.

admin-api

• TenantAdminController under /admin/api/v1/tenants:

  Verb	Path	Action
  POST	/	create
  GET	/	list
  GET	/{id}	fetch
  PUT	/{id}	rename
  PUT	/{id}/activate	activate
  PUT	/{id}/deactivate	deactivate
  DELETE	/{id}	delete

• CreateTenantRequest + RenameTenantRequest DTOs (Jakarta Validation)

Design note

platform_tenant.id is a varchar(64) slug rather than UUID so existing tables that already carry tenant_id as a string slug keep working without FK migration churn. Consumer apps that want strict referential integrity can add the FK in their own migration on top.

Verified

./gradlew :devslab-kit-sample-app:test  → BUILD SUCCESSFUL in 56s

• V7 applies cleanly on top of V1-V6
• TenantService bean wires
• All previous beans + login flow + admin-api controllers still green