[P1] Standardize exception handling and HTTP error semantics

[jjoonleo]

Problem

Error handling is incomplete and inconsistent. Many service methods throw IllegalArgumentException, NoSuchElementException, or raw RuntimeException, while GlobalExceptionHandler only handles selected exception types.

Why this is not production ready

Unexpected exceptions become generic 500s, clients receive inconsistent response bodies, and operational logs mix expected business errors with real server failures. Some business error codes also use custom numeric codes that can be confused with HTTP status codes.

Evidence

• GlobalExceptionHandler handles GeneralException, InvalidTokenException, and HttpMessageNotReadableException only.
• Services throw raw exceptions such as IllegalArgumentException, NoSuchElementException, and RuntimeException in many paths.
• ErrorCode.UNAUTHORIZED_ACCESS uses HTTP 401 for an ownership/authorization failure that may be better represented as 403.
• Some controller/filter failure paths write ad-hoc JSON strings instead of ApiResponseForm.

Required work

• Standardize business exceptions on GeneralException/ErrorCode or a small exception hierarchy.
• Add global handlers for validation errors, access denied, unsupported methods, type mismatch, and unexpected exceptions.
• Ensure all errors return the same response envelope and correct HTTP status.
• Add request/correlation ID to error responses/logs.
• Review 401 vs 403 usage for authentication vs authorization failures.

Acceptance criteria

• Known business errors never leak as generic 500s.
• All controller/filter error responses share a consistent schema.
• Tests cover malformed JSON, validation failure, unauthorized, forbidden, not found, and unexpected exception cases.