CLPR-1.7: Local misbehavior detection

## Story CLPR-1.7: Local Misbehavior Detection

**Parent Epic:** #24484 (CLPR-1: Network Layer)

### Objective

Implement local misbehavior detection in the endpoint module: tracking sync frequency per remote endpoint and detecting duplicate bundle submissions by local endpoints.

### Acceptance Criteria

- **AC-1:** The endpoint module tracks inbound sync frequency per `(connection_id, peer_endpoint_account_id)` using the `endpoint_signature` recovered via ecrecover.
- **AC-2:** When a remote endpoint exceeds `max_syncs_per_sec`, the local node shuns that endpoint (rejects further syncs, penalizes reputation score).
- **AC-3:** When a local endpoint submits a duplicate bundle (same `proof_bytes` already submitted by another local endpoint), the duplicate is detected and the submitter's reputation is penalized.
- **AC-4:** Misbehavior detection is strictly local — there is no cross-ledger misbehavior reporting protocol.
- **AC-5:** Detection state is ephemeral (in-memory, not persisted to the Merkle tree). It resets on node restart.
- **AC-6:** Shunning is temporary — the penalty decays over time and the endpoint can be selected again.

### Notes

- This story is closely related to CLPR-4.3 (sync orchestration and peer selection) and may be implemented together.

### Dependencies

- CLPR-4.1 (gRPC server — inbound syncs to monitor)
- CLPR-4.3 (sync orchestration — reputation system)

### Risk

**Low** — Local-only detection with ephemeral state. No cross-ledger coordination needed.

Start with the endpoint module and the CLPR-4.1 gRPC server, then read the related CLPR-4.3 sync orchestration and reputation-system work. Implement the acceptance criteria for frequency tracking, duplicate bundle detection, temporary penalties, and in-memory reset behavior; completion should preserve strictly local detection without cross-ledger reporting.

Written by the indexing model from the issue text.