[Bug]: GET /api/logs/audits?limit=0 returns all rows instead of zero, due to falsy-zero check

What's the bug?

The audit log query endpoint (GET /api/logs/audits) destructures limit/offset from req.query, converts them with Number(...), and passes them into AuditService.query().

In backend/src/services/logs/audit.service.ts, lines 120-123:

if (query.limit) {
  dataSql += ` LIMIT $${paramIndex++}`;
  dataParams.push(query.limit);
}

This check uses truthiness, so query.limit === 0 is treated the same as "no limit specified." When a caller explicitly passes limit=0, no LIMIT clause is added to the SQL query at all — so instead of returning zero rows, the query returns the entire audit log table.

Note: the sibling check on offset (line 125, if (query.offset)) uses the same pattern but is harmless, since OFFSET 0 and no OFFSET are equivalent. This asymmetry is specific to limit, where 0 and "unset" are not equivalent.

Also note: the endpoint sits behind verifyAdmin, but the defect itself is pure SQL-construction logic, not an authentication/authorization bug.

How to reproduce

1. As an admin, send GET /api/logs/audits?limit=0
2. Expected: zero records returned
3. Actual: the entire audit log table is returned

Environment (optional)

N/A — this is a backend logic bug, not environment-specific.

Test coverage gap: backend/tests/unit/audit.service.test.ts only tests AuditService.log() — nothing exercises query(), so no existing test covers limit/offset behavior.

Suggested fix: Change the check to query.limit !== undefined (or an equivalent explicit check) so that limit: 0 is honored and correctly emits LIMIT 0.