fix(local-ui): scope service filters to rendered signals

[robbiemu]

Summary

• Build the Logs tab's Service filter from raw logs, using the same exact TimestampTime and Timestamp bounds as the rendered Logs list.
• Own one anchored time window in LogsView and pass it to the list, Service facet, and Severity facet; filter changes and manual refresh advance that shared anchor.
• Include the shared bounds in every Logs query key so independently cached queries cannot drift onto different runtime windows.
• Return the complete raw service membership without a query-level cap.
• Keep trace and metric service filters tied to their existing signal-specific data paths, and remove the shared trace-derived useLocalServices hook.

Why

The former shared Service filter was sourced from trace-oriented service overview data, so logs-only services were absent. The first version of this PR moved Logs to logs_aggregates_hourly, but that was still not exact:

• non-hour-aligned ranges could omit services from a partial leading hour;
• the 365-day aggregate could retain services after the corresponding 30-day raw logs were no longer renderable, including after coordinated retirement;
• independently computed relative time bounds could let a refreshed list move ahead of cached facets; and
• a 500-group backend limit could silently omit a renderable service.

The Logs filter now performs an unbounded raw breakdown over the exact page-owned bounds used by logsListQuery. A service can therefore appear in the filter if and only if at least one raw log for it is renderable in that selected time window.

Validation

• Based directly on current upstream main at f74baa90.
• All local-UI tests passed (9/9), including a fake-clock hook regression that advances the shared window before a later filter render.
• The full query-engine suite passed (965/965).
• Non-hour-aligned 13:05–14:05 regression asserts all four exact raw time predicates.
• Stale-aggregate regression asserts the service query has no logs_aggregates_hourly dependency.
• High-cardinality regression asserts the service query emits no LIMIT; existing breakdown callers retain their default limit.
• @maple/local-ui and @maple/query-engine typechecks passed.
• Formatting, oxlint, and git diff --check passed (one pre-existing Logs useEffect warning remains).
• Production local-UI build passed against upstream's current combobox implementation.

This PR intentionally excludes the telemetry-retention work from PR #294. The deployment repository can combine both reviewed changes later.