DLQ resend results do not identify failed messages

## Problem

DLQ resend endpoints currently report only aggregate counts. `DLQResendResultVO` contains `matched`, `resent`, `failed`, `outcome`, `scanIncomplete`, and `failedQueueCount`, but no per-message failure information.

When a resend returns `PARTIAL` or `FAILED`, the operator still has to find the failed message IDs manually. The current response cannot answer the first questions asked during an incident:

- which dead-letter messages were not sent?
- which target topic did each failed resend use?
- why did the individual resend fail (missing target topic, producer send failure, or no resolvable destination)?
- were failures omitted from the response because a very large batch exceeded a display limit?

The selected-message resend path has the same limitation: if one of the selected messages fails, only `failed=1` is returned.

## Expected behavior

- Each failed resend should report a bounded failure entry containing the dead-letter `msgId`, resolved target topic, and a concise reason.
- Both time-range resend and selected-message resend should return the same failure-detail structure.
- The failure list should be capped (for example 100 entries) and expose whether additional failures were omitted.
- Existing aggregate fields and outcome classification should remain unchanged.
- The frontend should show the failed message IDs and reasons for `PARTIAL`/`FAILED` results so operators can retry or inspect the affected messages immediately.

Start with DLQResendResultVO and trace both time-range and selected-message resend endpoints to see how aggregate outcomes are built. Then inspect the frontend handling of PARTIAL and FAILED responses. Done means both paths return a bounded, omission-aware failure list with msgId, target topic, and reason, while the frontend displays those details and existing aggregates remain unchanged.

Written by the indexing model from the issue text.