perf(java): remove extra count/query amplification from paginated list endpoint

[davideme]

Problem

The Java list endpoint currently performs avoidable extra database work on the hot path. In LampService.findAllActivePage, we fetch a paginated result and then perform an additional countActive() call to compute hasMore. Depending on JPA pagination behavior, this can result in 2-3 queries per list request.

Goal

Reduce per-request SQL for list pagination to a single data query by switching to a pageSize + 1 strategy (or equivalent Slice approach) and deriving hasMore without count queries.

Scope

• Update Java pagination implementation for /v1/lamps list path.
• Remove hot-path dependence on countActive() for pagination metadata.
• Keep existing API behavior (data, hasMore, nextCursor) unchanged.

Suggested implementation

• Replace Page-based flow with one of:
  • Slice in Spring Data JPA, or
  • custom repository query that fetches limit = pageSize + 1 and computes hasMore from returned row count.
• Preserve deterministic ordering (createdAt, id).

Acceptance criteria

• List endpoint no longer executes count query on hot path.
• Per list request SQL is reduced to one fetch query in normal case.
• Existing unit/integration tests pass (and tests updated as needed).
• API contract and response semantics remain unchanged.
• Benchmark rerun shows improved Java p95/p99 for DB pass.

Notes

This is intended to close the gap with Go/TypeScript by eliminating query amplification, not by changing feature behavior.