CLPR-3.2: Connector Registration and Lifecycle

## Story CLPR-3.2: Connector Registration and Lifecycle

**Parent Epic:** CLPR-3: Payment & Routing Layer
**Repo:** hiero-ledger/hiero-consensus-node

### Objective

Implement `registerConnector`, `topUpConnector`, `withdrawConnectorBalance`, and `deregisterConnector` as both HAPI transactions and system contract methods.

### Acceptance Criteria

- **AC-1:** All four operations are available as both HAPI transactions (for off-chain callers) and system contract methods (for on-chain smart contracts).
- **AC-2:** `registerConnector`: Connection must be ACTIVE. `initial_balance` ≥ `clpr.minConnectorBalance`, `stake` ≥ `clpr.minConnectorStake`. Funds transferred from caller to CLPR service accounting.
- **AC-3:** `source_connector_address` identifies the counterpart on the peer ledger. Cross-chain index maps `(connection_id, source_connector_address)` → local Connector.
- **AC-4:** `connector_contract` must be a deployed contract.
- **AC-5:** `admin` defaults to transaction payer (HAPI) or `msg.sender` (system contract) if not specified.
- **AC-6:** Duplicate registration (same connection_id + source_connector_address) rejected.
- **AC-7:** `topUpConnector`: adds to `balance`. Connector admin required.
- **AC-8:** `withdrawConnectorBalance`: withdraws from `balance` (not `locked_stake`). Cannot withdraw below `clpr.minConnectorBalance`. Connector admin required.
- **AC-9:** `deregisterConnector`: returns remaining `balance` + `locked_stake` to admin account. Must NOT deregister if Connector has unresolved in-flight messages. Connector admin required.
- **AC-10:** `getConnector` available as a system contract `view` function.
- **AC-11:** Black-box tests: register via HAPI, register via system contract, top-up, withdraw, deregister, minimum balance/stake, duplicate rejected, admin enforcement, getConnector view, deregister with pending messages rejected, fund transfers correct

### Dependencies

- CLPR-3.1 (wire formats)
- CLPR-1.4 (Connection)

### Risk

**Medium** — Dual HAPI + system contract pattern. Fund transfer mechanics.

Start by reviewing the CLPR-3.1 wire formats and CLPR-1.4 Connection dependency, then trace how HAPI transactions and system contract methods are exposed. Use the listed black-box scenarios to cover registration, funding, administration, duplicate handling, views, and pending-message rejection; done means all four operations work through both interfaces with the stated balance and stake rules.

Written by the indexing model from the issue text.