CLPR-1.4: Connection registration

## Story CLPR-1.4: Connection Registration

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

### Objective

Implement the `ClprRegisterConnection` handler, enabling anyone to register a Connection to a peer ledger using an ECDSA secp256k1-derived Connection ID, an immutable verifier contract, and a verified peer configuration.

### Acceptance Criteria

- **AC-1:** Connection ID is `keccak256(uncompressed_public_key)` where `uncompressed_public_key` is the 64-byte `x||y` (without `0x04` prefix). The caller provides both the public key and the pre-computed Connection ID; the handler verifies they match.
- **AC-2:** ECDSA secp256k1 signature verified over `keccak256(connection_id || verifier_contract_address || caller_account_id)`. Invalid signature rejected.
- **AC-3:** `verifier_contract` (AccountID) must reference a **deployed** system contract. The handler computes the verifier's `keccak256(bytecode)` fingerprint and stores it on the Connection as an informational field. The verifier is immutable after registration. If the contract doesn't exist, the transaction fails.
- **AC-4:** The caller must supply `config_proof_bytes` — an opaque proof from the peer ledger containing the peer's configuration. The handler calls `verifyConfig(config_proof_bytes)` on the supplied verifier contract and stores the verified `ClprLedgerConfiguration` (chain_id, service_address, throttles, timestamp) on the Connection. If verification fails, the transaction fails.
- **AC-5:** Duplicate `connection_id` rejected.
- **AC-6:** Initial Connection status is `ACTIVE`. The Connection is immediately operational after registration.
- **AC-7:** Queue metadata initialized: `next_message_id = 1`, `acked_message_id = 0`, `sent_running_hash = 32×0x00`, `received_message_id = 0`, `received_running_hash = 32×0x00`.
- **AC-8:** `peer_config_timestamp` initialized from the verified peer configuration's timestamp.
- **AC-9:** Permissionless. No special key required beyond the transaction payer.
- **AC-10:** Transaction record includes the `connection_id`.
- **AC-11:** Black-box tests: successful registration with verified peer config, duplicate ID rejected, invalid ECDSA signature rejected, verifier contract not deployed rejected, verifier rejects config_proof_bytes rejected, queue metadata correctly initialized, peer config populated from proof, connection starts ACTIVE

### Notes

- There is no deposit or anti-griefing bond for Connection registration on Hiero.
- The verifier cannot be changed after registration. If the peer upgrades its proof format, a new Connection must be registered with a new verifier.
- The peer endpoint roster is NOT populated at registration time. The caller must separately call `ClprUpdateEndpointRoster` with a state proof to populate it before syncing can begin.

### Dependencies

- #24485 (CLPR-1.1: wire formats and state schema)
- CLPR-5.1 (verifier interface — `verifyConfig` must be callable)

### Risk

**Medium** — ECDSA signature verification, verifier bytecode fingerprinting, and verifier contract invocation (`verifyConfig`) all required in the registration flow.

Start by locating the ClprRegisterConnection handler and reviewing the wire formats and state schema from dependency #24485. Check the verifier interface dependency and implement against the listed black-box scenarios, including signature and contract validation, verified configuration, duplicate rejection, queue initialization, and an ACTIVE connection with the connection_id in the transaction record.

Written by the indexing model from the issue text.