qkc/slave 05: add MasterConn protocol layer

[iteyelmp]

Add MasterConn: the slave-side master↔slave connection layer

Introduces MasterConn, the slave's TCP connection to the cluster master, built on the existing BaseConn. This PR covers protocol compatibility and handler registration only; cluster business logic is intentionally deferred.

Scope

• 12-byte ClusterMetadata framing over TCP (master↔slave).
• Master→Slave opcode / serializer / handler registration, including the DESTROY_CLUSTER_PEER_CONNECTION_COMMAND non-RPC opcode.
• Outbound RPC helpers: SendAddMinorBlockHeader, SendAddMinorBlockHeaderList.
• Business RPCs are delegated through the MasterHandler interface; the service layer implements it later.

Not in Scope

• Cluster business logic (shards, miner, chain state).
• Dispatcher / PeerConn / virtualTransport / cluster peer registry (later PRs).

Reviewer notes

Handler boundary

MasterConn owns protocol framing, opcode dispatch, and connection-level
communication behavior.

PING has two responsibilities:

• protocol handshake (reply with slave identity via PONG);
• runtime notification when a RootTip is attached.

The handshake remains in MasterConn. RootTip processing is delegated through
MasterHandler because shard initialization/update is runtime behavior rather
than connection-layer behavior.

All other master-driven operations are delegated through MasterHandler. This
PR intentionally defines protocol wiring and dispatch only; business logic is
implemented in later PRs.

Create / Destroy semantics

CREATE is a normal RPC (request/response).

DESTROY is a fire-and-forget non-RPC command: rpc_id must be zero and no
response frame is written. It is registered via NonRPCOps; the placeholder
ResponseOpCode exists only for opcode registration consistency and is never
observed on the wire.

Full Codex 5.6 review completed.