fix(xmr): S04A - retain FROST keysign traffic across phase skew

Series context

This is S04A of the focused replacement MRs for the superseded XMR MR !4983 (closed).

• Scope: XMR FROST keysign phase coordination and verification-echo batching
• Depends on: S00 !5026-keygen and simulation support.
• Merge: S00 into develop -> rebase/retarget & merge this MR S05A.
• Follow-ups:
  • S02(!5038) — minimum FROST ingress, queue, reader, and writer bounds
  • S03 — stream ownership, party narrowing, cancellation, and successful close
  • S04B — additional scheduling only if measurements prove it necessary

Problem

FROST keysign previously consumed preprocess payloads, share payloads, verification echoes, and terminal results through one shared channel.

Participants do not necessarily advance through the protocol simultaneously. A faster participant can send share-phase traffic while another participant is still in preprocess. The slower participant could consume and discard that future traffic, preventing signing from completing.

A participant can also receive successful terminal-result votes before its local signing attempt finishes. Those votes must remain available so it can adopt the successful quorum result.

Finally, broadcasting every verification echo separately creates substantial stream and goroutine churn. At the supported 128-participant boundary, the unbatched two-round verification path can produce 32,512 remote stream writes per node.

Changes

Preserve traffic across phase skew

• Route preprocess, share, verification, and result traffic through separate bounded inboxes.
• Keep future share payloads queued until the share phase starts.
• Retain future share verification entries together with their authenticated transport peer.
• Defer sender binding, transcript validation, and equivocation handling until the share phase.
• Apply retained and queued terminal evidence before constructing or broadcasting the local share.
• Retain early terminal-result votes for the result quorum collector.
• Drain obsolete phase traffic while waiting for terminal results so full queues cannot park stream handlers or retain frame buffers until timeout.
• Use one subscription table for registration, party narrowing, and cancellation.

Batch signed verification echoes

• Reuse !5026’s bounded homogeneous verification-batch format.
• Coalesce signed verification echoes for up to 100 ms.
• Flush on:
  • the 128-entry limit,
  • the coalescing tick, or
  • round exit.
• Require every batch to contain one sender and one round.
• Validate and account for every logical entry independently.
• Preserve sender-to-peer binding, participant-index checks, signed-envelope validation, duplicate idempotency, and portable equivocation evidence.

At 128 participants, the deterministic traffic fixture records:

Shape	Queue tasks	Writer launches	Remote stream writes
Coalesced whole ceremony	5	640	635
Maximum valid fragmentation	259	33,152	32,893

Batching substantially improves the normal coalesced path. It cannot reduce the finite worst case where every logical echo arrives in a separate non-empty tick window.

Compatibility and rollout

The keysign verification-batch format is intentionally not backward-compatible with legacy single-echo messages.

This is acceptable under the planned rollout assumptions:

• no previous XMR FROST keysign ceremony exists,
• no ceremony may be active or resumed during deployment,
• no mixed-version XMR FROST ceremony is supported,
• XMR economic activity remains halted until every intended participant runs the same reviewed batch-capable build.

No legacy decoder, wire negotiation, or capability probing is added.

Resource bounds and follow-ups

Local XMR keysign concurrency is one because sidecarSignMu spans the sole production FrostKeySign call.

This MR retains the existing per-frame, per-peer, per-session, and per-topic queue limits. S02 will add the remaining aggregate reader, queued-task, and actual peer-writer bounds using the traffic shapes established here.

Out of scope

This MR intentionally does not include:

• aggregate FROST transport budgets or scheduling,
• process cancellation or phase-deadline redesign,
• party-narrowing and StreamMgr ownership fixes,
• successful-stream close ownership,
• DKG or result transport retries,
• THORNode consensus or activation changes,
• legacy verification decoding or mixed-fleet compatibility.