CLPR-2.5: Message redaction

## Story CLPR-2.5: Message Redaction

**Parent Epic:** CLPR-2: Messaging Layer
**Repo:** hiero-ledger/hiero-consensus-node

### Objective

Implement `ClprRedactMessageHandler` per cross-platform spec §4.4 and §6.4.

### Acceptance Criteria

- **AC-1:** Accepts `connection_id` and `message_id`.
- **AC-2:** Payload removed. `running_hash_after_processing` retained. Message slot preserved.
- **AC-3:** Redacting an already-redacted or already-acknowledged message fails.
- **AC-4:** Non-existent message fails.
- **AC-5:** Running hash verification skips redacted slots by using the stored `running_hash_after_processing` directly.
- **AC-6:** When a redacted message is transmitted in a bundle, the destination receives an empty `ClprMessagePayload` (all fields unset). The receiving ledger recognizes this and generates a deterministic `REDACTED` response.
- **AC-7:** Requires CLPR admin key. `preHandle` adds admin key.
- **AC-8:** Black-box tests: successful redaction, already-redacted error, not-found error, admin key enforcement, running hash chain integrity preserved, redacted message in bundle produces REDACTED response

### Dependencies

- CLPR-2.1 (wire formats)
- CLPR-2.2 (messages must exist in queue)

### Risk

**Low** — Payload removal with hash preservation.

Start with cross-platform spec sections §4.4 and §6.4, then review the CLPR-2.1 wire formats and CLPR-2.2 message-queue behavior. Use the listed black-box scenarios to define coverage, including admin-key enforcement, hash-chain handling, and bundled redacted messages. Done means all acceptance criteria pass without changing the message slot or retained running hash.

Written by the indexing model from the issue text.