CLPR-4.4: Bundle Submission Pipeline

## Story CLPR-4.4: Bundle Submission Pipeline

**Parent Epic:** CLPR-4: Hiero Endpoint
**Repo:** hiero-ledger/hiero-consensus-node

### Objective

Implement the pipeline from received `ClprSyncPayload` to submitted `ClprSubmitBundle` transaction.

### Acceptance Criteria

- **AC-1:** Pre-verification: call verifier locally (read-only) against latest immutable state. Reject → discard, penalize peer reputation.
- **AC-2:** Transaction construction: `ClprSubmitBundleTransactionBody` signed by node's account key. Unique nonce per submission.
- **AC-3:** Submission via `SubmissionManager` (bypasses `IngestWorkflow` — direct to consensus).
- **AC-4:** Duplicate handling: replay rejection post-consensus is normal (another node submitted first). No retry, update reputation (normal).
- **AC-5:** Failure handling: throttle rejection → exponential backoff. Verification failure → no retry, reputation penalty. Network partition → buffer up to `clpr.maxPayloadBufferAge` (60s), then discard.
- **AC-6:** Duplicate reduction heuristics (Hiero-specific): random delay before submission (stagger across nodes), check `received_message_id` in latest state before submitting.

### Dependencies

- `SubmissionManager`, transaction signing
- CLPR-2.3 (SubmitBundle handler)
- CLPR-4.2 (pre-verification)

### Risk

**Medium** — SubmissionManager integration. Nonce management.

Read the SubmissionManager and transaction-signing integration first, then review CLPR-4.2 pre-verification and the CLPR-2.3 SubmitBundle handler. Done means implementing the stated verification, signing, submission, duplicate, retry, buffering, and duplicate-reduction behavior, including nonce management.

Written by the indexing model from the issue text.