fix(web): validate usage summary date range

[iscekic]

Request

Surface: backend services (apps/web server routes and lib).

The usage summary endpoint accepts a date range but does not validate it: an end date before the start date returns a confusing empty result instead of a 400. Reproduce first against the live dev backend with two requests (a valid range and an inverted one). If it already returns a clear 400, stop with the evidence and no code change. If it does not, return a 400 with a specific message, keep the existing response shape for valid ranges, add a test beside the existing route tests, and prove both paths live in the PR body.

Request

Surface: backend services (apps/web server routes and lib).

The usage summary endpoint accepts a date range but does not validate it: an end date before the start date returns a confusing empty result instead of a 400. Reproduce first against the live dev backend with two requests (a valid range and an inverted one). If it already returns a clear 400, stop with the evidence and no code change. If it does not, return a 400 with a specific message, keep the existing response shape for valid ranges, add a test beside the existing route tests, and prove both paths live in the PR body.

Changelog for users

• The usage summary endpoint now returns an HTTP 400 with the message endDate must not be before startDate when the requested end date is before the start date, instead of a silently empty result.
• Valid date ranges, including a window where the start and end instants are equal, keep the existing response shape.

Changelog for maintainers

• The shared usage-analytics filter schema now runs a superRefine that attaches a custom endDate issue with message endDate must not be before startDate whenever endDate is earlier than startDate; the existing tRPC input parsing already surfaces this as BAD_REQUEST, so no router code changed.
• The comparison uses millisecond timestamps, so an equal start/end instant (a legitimate empty window) still validates.
• Tests added beside the existing route tests: the schema rejects an inverted range on the endDate path, valid and equal-instant ranges stay accepted, and getSummary rejects inverted input with BAD_REQUEST without calling the Snowflake statement mock.

E2E proof

[e1] The usage summary endpoint accepts a date range but does not validate it: an end date before the start date returns a confusing empty result instead of a 400. — Recording e1-date-range.webm; final e1-both-responses.png (also e1-valid-range.png, e1-inverted-range.png, e1-valid-range.json, e1-inverted-range.json). Authenticated POST /api/trpc/usageAnalytics.getSummary: valid start=2026-06-04 end=2026-06-05 returned HTTP 500 INTERNAL_SERVER_ERROR 'Usage data…

e1-date-range.webm.trim.mp4