dev-javalisted

# Java Implementation ## Overview Implement Java changes against the repository's pinned JDK, build owner, framework generation, module boundaries, security model, transaction semantics, and runtime contracts. Treat reference projects such as RuoYi as comparative evidence, never as a template that overrides current source. ## Workflow 1. Read effective repository guidance and run `git status --short` in the owning Git root before edits. 2. Resolve the owning Maven or Gradle build root, target module, executable or library role, effective JDK source, Wrapper, parent/BOM/platform, profiles, and repository-defined commands. Stop before source edits when the Git/build root, target module, or intended JDK contract cannot be resolved. When an existing authority conflict is the explicit task target and user intent or an approved contract establishes the intended authority, permit only the bounded changes needed to resolve that conflict. Record other missing build/runtime authorities as `Not verified` and do not make changes that depend on them. 3. Classify the project: compact service, modular monolith, multi-module application, shared library/SDK, batch or scheduler, CLI, or legacy platform application. 4. Read the approved behavior/specification when one exists. Confirm compatibility, affected modules and public seams, data/security impact, non-goals, and validation expectations. When runtime/configuration, packaging, API/integration, persis