Message key queries and trace lookups return 502 for empty results (NO_MESSAGE not graded)

## Problem

`RocketMQMessageProvider` (server, Apache provider) surfaces the RocketMQ client's "no data" signal as a gateway error. `MQAdminImpl.queryMessage` throws `MQClientException(ResponseCode.NO_MESSAGE=208, "query message by key finished, but no message.")` when a key query matches nothing — it never returns an empty `QueryResult`. The provider's catch-alls convert that into `BusinessException(502)`:

- Key-based message search (`queryByKey`, reached from `GET /api/messages` and `GET /api/messages/page`): a search key with zero matches — a normal outcome — responds 502 "Failed to query messages by key: CODE: 208 ...".
- Message trace (`getMessageTrace`, `getMessageTraceByKey`): a message without trace data (trace disabled on the producing client, or records expired) responds 502 instead of an empty trace. The code's own grading comment states "the RPC succeeded but there is no business data, so return an empty trace instead of surfacing an error", but only `ResponseCode.TOPIC_NOT_EXIST` is graded — `NO_MESSAGE` is not.

## Evidence / source

- Bytecode of `rocketmq-client-5.5.0.jar` (the version resolved by `server/pom.xml`): `MQAdminImpl.queryMessage` ends with `new MQClientException(208 /* NO_MESSAGE */, "query message by key finished, but no message.")` when the result is empty.
- `RocketMQMessageProvider.java` (base commit 36126024): `queryByKey` catch-all throws 502; `isTraceTopicAbsent` matches only `TOPIC_NOT_EXIST`; `getMessageTraceByKey` has no grading at all.
- Closed issues #1161 and #1275 record the intended semantics: a completed query with no matching records may return an empty result; only a remote query failure must return a structured gateway error. `NO_MESSAGE` is exactly the former.

## Impact

First-class query modes on the Message page error out for normal empty outcomes: searching a key that does not exist, and viewing the trace of any message produced without trace data (a very common configuration), both present a 502 error instead of an empty state.

## Expected behavior / acceptance criteria

- Key queries grade `NO_MESSAGE` and return an empty list; trace lookups grade `NO_MESSAGE` alongside `TOPIC_NOT_EXIST` and return an empty trace.
- Genuine broker/ACL/network failures continue to surface as 502 (existing failure-surfacing tests stay green).
- Regression coverage for the no-match paths with the client's 208 exception; it must fail on the unfixed code.

## Related work

- #1161 / #1275 (closed) established the empty-vs-failure distinction this issue completes for the client's own "no message" response code.

## PR

PR #3302 (includes the fix and three regression tests).

Start with RocketMQMessageProvider.java and the RocketMQ client version resolved in server/pom.xml. Review the existing query and trace error-handling paths, then run the regression coverage described in the issue. Done means empty key-query and trace results are returned as empty values, while genuine broker, ACL, and network failures still produce 502 responses.

Written by the indexing model from the issue text.