CLPR-1.3: Approved verifiers management

## ⚠️ This issue is OBSOLETE — recommend closing as "won't do"

The entire "approved verifiers" concept was removed from the CLPR specification. The current spec works as follows:

1. **Verifier is per-Connection, not per-ledger.** The registrant chooses a verifier contract at Connection registration time.
2. **Verifier is immutable.** It cannot be changed after registration (cross-platform spec §5.1, design doc §3.1.3).
3. **No approved verifiers map.** There is no ledger-wide whitelist of verifier labels or code hashes.
4. **No `ClprUpdateConnectionVerifier` transaction.** The concept doesn't exist.
5. **No auto-pause cascades.** Since there's no verifier whitelist to remove entries from, there's no cascade.
6. **No verifier label system.** Connections reference a `verifier_contract` (AccountID) directly.
7. **No resume guards based on verifier approval.** Resume simply transitions PAUSED → ACTIVE.

### What Replaced It

- **#24510 (CLPR-1.4: Connection Registration):** The verifier contract address and its `keccak256(bytecode)` fingerprint are stored on the Connection at registration time. The fingerprint is informational. The verifier's `verifyConfig()` is called during registration to verify the peer's configuration proof.
- **CLPR-5.1 (IClprVerifier Interface):** Verifier contracts implement `IClprVerifier` and are deployed as system contracts.

Read the issue's replacement references, #24510 (CLPR-1.4) and CLPR-5.1, alongside the current CLPR specification to confirm that approved verifiers are no longer part of the design. The work is done when this obsolete issue is closed as "won't do"; no implementation or tests are identified.

Written by the indexing model from the issue text.