[Feature]: Dashboard metrics and security anomalies accept no time range

[Bccorb]

Problem statement

The /internal/auth-events/* endpoints all accept a time range. Two neighbouring internal endpoints that feed the same operator screens do not, so a console cannot offer one coherent range control.

From openapi.json at 4bbed05:

Endpoint	Query parameters
GET /internal/auth-events/timeseries	userId, from, to, interval
GET /internal/auth-events/summary	userId, from, to, interval
GET /internal/auth-events/grouped	userId, from, to, interval
GET /internal/auth-events/login-stats	userId, from, to, interval
GET /internal/metrics/dashboard	none
GET /internal/security/anomalies	none

The consequence in a console: an operator investigating an incident outside the default window can move the activity chart, the event distribution, and the login statistics, but the headline metric tiles beside them and the anomaly feed underneath stay pinned to their fixed windows. The screen would appear to respond to the range control while half of it silently did not, which is worse than not offering the control at all.

/internal/metrics/dashboard also bakes its window into its response field names (loginSuccess24h, loginFailed24h, successRate24h), so a range parameter needs a decision about whether those names stay or the shape changes.

Proposed solution

Add from and to to both endpoints, matching the existing /internal/auth-events/* signature so callers can use one range model across all of them:

• GET /internal/security/anomalies — straightforward, filters the underlying event window. Worth adding limit/offset at the same time if the set can be large: it already returns { suspiciousEvents, total } but gives no way to reach anything beyond the first response.
• GET /internal/metrics/dashboard — needs a call on the response shape. Either keep the *24h field names and treat them as "the requested window" (misleading), or introduce window-neutral names and keep the old ones as deprecated aliases for a release.

If the metrics endpoint is meant to be a fixed 24-hour health snapshot by design, saying so in the OpenAPI description is a perfectly good outcome too. The problem is that the current state is indistinguishable from an omission, so a caller cannot tell whether to wait for the parameter or design around its absence.

Alternatives considered

Leaving both fixed and labelling the affected tiles as fixed-window in the console. Workable, and it is the fallback if these parameters are not wanted, but it makes one screen carry two different time semantics with a caption explaining the seam.

Filtering client-side is not possible: both endpoints return aggregates rather than raw events.

Impact area

Developer experience

Additional context

Blocks the remainder of fells-code/seamless-auth-admin-dashboard#148, which has been rescoped around exactly this split: the three /internal/auth-events/* consumers can get a range control now, and these two cannot.