Message Explorer hides the message properties returned by the backend

## Problem

The backend already returns message properties with each `MessageRecordVO`:

```java
private Map properties;
private boolean propertiesTruncated;
```

The provider deliberately limits this data to 64 properties and 1,024 characters per value, and exposes `propertiesTruncated` when that contract shortens the display payload.

However, the Message Explorer does not show this data anywhere:

- the message detail modal shows only basic metadata and the body;
- the queue browser message cards show Message ID, Tag, Key, store time, size, born host, and body;
- the frontend `MessageRecord` type omits `propertiesTruncated`, even though `properties` is already present.

As a result, an operator investigating delivery headers, trace flags, retry context, or business user properties must use another tool. The data is already delivered by the backend but is invisible in the UI.

## Expected behavior

- Add `propertiesTruncated` to the frontend message record contract.
- Show message properties in the message detail modal in a readable, bounded area.
- Show properties in queue-browser message cards as well.
- When `propertiesTruncated` is true, show a warning that the server shortened the property payload.
- Keep body display and existing metadata behavior unchanged.

## Why this matters

Message properties are commonly used for routing metadata, trace identifiers, deduplication keys, retry context, and business headers. During incident triage, seeing them alongside the body avoids guessing why a message was routed, retried, or traced.

Start with the frontend MessageRecord type, the message detail modal, and the queue-browser message cards described in the issue. Trace how properties and the backend's propertiesTruncated value reach those entry points. Done means both views show bounded properties, warn when the payload was truncated, and preserve the existing body and metadata display.

Written by the indexing model from the issue text.