refactor(examlense): reorganize backend into package-by-feature slices

[zhngharry]

Converge the backend on package-by-feature vertical slices. Dissolve the layer-based api/ and persistence/ packages: each domain (exam, section, task, grading, admin) now owns its controller + service + entity + repository + DTOs, alongside the existing parse/solve/lgh slices. Keep cross-cutting technical modules shared (ai, storage, sse, security, config, error, prompts) and add a shared/ package for Access, Patch, and DefaultUser.

Split the monolithic Dtos.java into per-slice DTO holders and the cross-domain CrudService into ExamService/SectionService/TaskService. Pure package reshuffle: no endpoint paths or DB schema change. Relocate tests beside their subjects and update the backend README project layout.

[yinggez]

Copilot:

✅ Architecture Refactoring Approved

Excellent execution of a complex package reorganization. The move from layer-based (api/, persistence/) to vertical slices is clean and well-structured.
Strengths:

• ✅ Clear ownership: Each domain slice (exam, section, task, grading, admin) owns its full stack (controller + service + entity + repo + DTOs)
• ✅ Reduced coupling: Cross-cutting modules (ai, storage, sse, security, config, error, prompts) properly centralized; no layer-based bottlenecks
• ✅ Focused services: CrudService decomposed into ExamService, SectionService, TaskService — each single-purpose
• ✅ Monolithic DTO split: Dtos.java eliminated; each slice holds focused DTO records (ExamDtos, SectionDtos, TaskDtos, etc.)
• ✅ Import consistency: All 72 files correctly updated; no dangling or broken references
• ✅ Tests relocated: All tests co-located with their subjects; naming and structure clear
• ✅ Transaction safety preserved: @transactional annotations and atomic operations intact across all services
• ✅ No functional changes: Pure restructuring — no endpoint paths or DB schema changes as promised
• ✅ Follows existing pattern: Aligns cleanly with parse/, solve/, lgh/ slices already in the codebase

Minor: SectionService handles both sections and blocks; consider adding a note in the docstring explaining the operational coupling if future maintainers find this non-obvious.

Ready to merge. 🚀