Performance: batch item inserts and add pagination to list endpoints

[waritctd]

Severity: Low (performance / scalability)

Both are fine at today's data volumes; worth addressing before scale.

1. Per-row INSERT loops. TicketRepository.insertItems / replaceItems insert ticket items one statement at a time in a for loop (backend/src/main/java/th/co/glr/hr/ticket/TicketRepository.java:260). Use NamedParameterJdbcTemplate.batchUpdate for a single round-trip. (reWriteBatchedInserts=true is already set on the datasource, so this pays off immediately.)

2. List endpoints return everything (no pagination). GET /api/employees (EmployeeRepository.findEmployees) and GET /api/tickets have no LIMIT/offset or keyset pagination. Response and memory grow linearly with the table. Add pagination + a sane default page size.

Non-issues confirmed during review (no action): EmployeeService.list batches pending-counts (no N+1); ticket detail is a bounded 4-query fetch; the frontend parallelizes initial loads with Promise.all.

[waritctd]

Correction after a fuller index review: the schema is actually well-indexed (employee FK columns, ticket status/owner/dates, ticket_item/event, notification, attendance unique+lookup indexes, profile-request indexes). The one genuine missing index is on hr.employee.email, which is the login lookup hot path (EmployeeAuthRepository.findByEmail does LOWER(btrim(email)) = LOWER(:email) with no supporting index → sequential scan). Recommend a functional index, e.g. CREATE INDEX idx_employee_email_lower ON hr.employee (LOWER(btrim(email)));. The pagination point in this issue still stands.