fix(txsubmission): handle client MsgDone in server agent to avoid mempool stall

[nemo83]

Problem

The N2N TxSubmission server agent never handled a client MsgDone. When a peer
terminates the tx-submission mini-protocol with MsgDone while the server is
blocking-waiting in TxIdsBlocking, the state machine dropped it on the floor:

• TxSubmissionState.TxIdsBlocking.nextState() only transitioned on ReplyTxIds, so
  MsgDone returned this → the agent stayed wedged in TxIdsBlocking forever.
• In TxIdsBlocking the client holds agency, so the server can never send another
  RequestTxIds → repeated WARN Cannot request tx IDs in state: TxIdsBlocking.
• Because the agent never becomes Done, MiniProtoServerInboundHandler keeps it
  registered and later logs No agent found to handle protocol ....
• TxSubmissionServerAgent.processResponse() had no MsgDone branch, so it also logged
  WARN Unexpected message type: MsgDone.

Net effect: the node silently stops ingesting mempool transactions while
chain-sync and block-fetch keep working normally. Observed in production: the mempool
feed went dead and never recovered until the process was restarted.

Fix

• TxSubmissionState: transition to Done on MsgDone from the client-agency states —
  TxIdsBlocking (per the node-to-node tx-submission spec), plus TxIdsNonBlocking and
  Txs defensively.
• TxSubmissionServerAgent.processResponse: handle MsgDone explicitly (clear in-flight
  bookkeeping, log at INFO) instead of falling through to Unexpected message type.

Once the agent reaches Done, the inbound handler stops routing to it and a fresh agent
is created when the peer reconnects — restoring mempool ingestion automatically.

Tests

Adds unit tests to TxSubmissionServerAgentTest:

• testMsgDoneFromTxIdsBlockingTransitionsToDone — drives the agent into TxIdsBlocking,
  sends MsgDone, asserts it reaches Done / isDone().
• testMsgDoneStateTransitionsForAllClientAgencyStates — asserts the MsgDone → Done
  transition for TxIdsBlocking, TxIdsNonBlocking, and Txs.

Full suite for the class passes (15 tests, 0 failures).

Scope / risk

Low and localized (2 main-source files). It only adds handling for a legal protocol
message that was previously dropped; the happy path is unchanged.

[sonarqubecloud]

Quality Gate failed

Failed conditions
17.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud