[Studio][Feature] Allow the AI message trace tool to use a custom trace topic

## Problem

The Studio message REST API and `MessageService` support an optional custom trace topic when looking up a message trace, and the Message Explorer UI can persist and use that value. The AI/MCP tool `rmq.message.trace` exposes only `cluster`, `msgId`, and `topic`, so AI and CLI callers are forced to use the default trace topic even when a deployment stores traces elsewhere.

## Expected behavior

- Add an optional `traceTopic` string to the `rmq.message.trace` input schema.
- Forward the value through `MessageTraceToolHandler` to the existing four-argument `MessageService.getMessageTrace` method.
- Keep `cluster` and `msgId` as the only required fields.
- Preserve the current output schema and risk/permission classification.
- A missing or blank `traceTopic` keeps the existing default/provider behavior through `MessageService`.

## Acceptance criteria

- The canonical tool catalog advertises optional `traceTopic`.
- Handler coverage proves a supplied custom topic reaches `MessageService`.
- Existing message trace projection behavior remains unchanged.
- No new endpoint or provider-specific behavior is introduced.

## Scope

This issue only covers message-id trace lookup. Trace lookup by business key remains separate work.

Start with the canonical tool catalog and MessageTraceToolHandler, then inspect the existing four-argument MessageService.getMessageTrace method and its current callers. Add handler coverage showing that a supplied traceTopic reaches the service, while confirming the existing output projection and risk/permission classification remain unchanged.

Written by the indexing model from the issue text.