Message Key queries cannot narrow by time range or tag

## Problem

Message Key queries are less useful than Topic queries during incident triage.

The backend already accepts `topic`, `key`, `tag`, `startTime`, and `endTime` for message queries. The frontend normalizer also passes those fields through. But in Message Key mode the UI only exposes:

- Topic
- Message Key

The date range picker and tag input are rendered only for Topic mode. As a result, users searching by business key cannot narrow a large result set by time or tag from the UI, even though the API supports both.

The backend also skips time-window validation whenever a key or message ID is present. If a client sends an invalid key-query window, it is accepted rather than rejected with the same validation used for topic queries.

## Expected behavior

- Message Key mode should expose the same time range picker and optional tag input as Topic mode.
- Key queries should include `startTime`, `endTime`, and optional `tag` when supplied.
- Key-query time windows should be validated consistently:
- start must be before end;
- timestamps must not be negative;
- the window must not exceed seven days.
- Message ID lookups should remain point lookups and should not require a time window.
- Query history replay should preserve the key query time window and tag.

Start with the Message Key mode UI and compare its controls and query construction with Topic mode. Then trace backend message-query time-window validation and query history replay. Done means key queries expose and preserve startTime, endTime, and tag, validate windows consistently, and leave message ID lookups as point queries.

Written by the indexing model from the issue text.