Refactor Getter.java and Setter.java into DAO pattern

Context

Getter.java (2847 lines, 52+ methods) and Setter.java (1567 lines, 28+ methods) are monolithic data access classes that handle all database operations. This makes them hard to maintain, test, and review.

Proposal

Refactor into a DAO (Data Access Object) pattern, splitting by domain:

• UserDao — auth, user creation, password management, role updates
• ModuleDao — module retrieval, status, scoring, cheat sheets
• ClassDao — class management, scoreboards
• SessionDao — CSRF tokens, session management helpers
• SettingsDao — platform configuration (registration, feedback, scoreboard settings)

Each DAO would:

• Use try-with-resources for all connections (no leak risk)
• Be independently testable
• Have a clear, focused responsibility

Prerequisites

• Connection leak fixes (part of #800) should be done first — fixing leaks on the current structure, then refactoring
• Should not change any business logic, only code organization

Benefits

• Smaller, reviewable files
• Easier to add tests per domain
• Clear ownership of database operations
• Reduces merge conflicts when multiple contributors work on different features

Start by reading Getter.java and Setter.java to inventory their database operations by the proposed domains. Complete the connection leak fixes from #800 first, then split the operations into UserDao, ModuleDao, ClassDao, SessionDao, and SettingsDao. Done means focused, independently testable DAOs using try-with-resources without changing business logic.