[masarray]

What changed

• add a portable bounded MmsRcbPreclaimFailoverTracker with explicit attempt, exclusion, selection, and exhaustion evidence;
• re-probe the selected Dynamic RCB immediately before mutation;
• skip candidates that become enabled, reserved, or flap between probes;
• rerank the next candidate through the existing Smart RCB selector with a command-local exclusion set;
• expose CLI bounds for candidates, probe count, probe delay, and recorded cooldown;
• update the reporting profile and feature matrix with current live and pending acceptance boundaries.

Why

Discovery evidence can become stale between inventory and claim. A preferred RCB may be free during discovery but owned by another client milliseconds later. The previous harness selected once and moved directly into the Dynamic DataSet lifecycle.

This change closes that pre-claim race without making mutation retry unsafe. Smart switching is allowed only while all operations remain read-only. Once any mutation is attempted, the command stays on the original candidate for cleanup and diagnostics.

Collaboration boundary

This is client-side selection/live-trial work based on current main. It does not modify the server-side static BRCB history, ownership, persistence, or recovery implementation under draft PRs #16 through #23, and it does not touch Smart Control, File Transfer, or MMS Server worktrees.

Validation

• MSVC warnings-as-errors full CTest: 23/23 passed;
• dedicated Dynamic RCB build/CTest: 2/2 passed;
• new failover regression target passed preferred-candidate contention, reranking, flapping, duplicate rejection, and hard attempt bounds;
• read-only isolated-lab plan passed three stable pre-claim probes and ended with READ_ONLY_PLAN_OK;
• no MMS Write, Define, Delete, reservation, or RptEna operation was sent during live validation.

Live proof of a genuinely contended candidate switching to a second RCB remains pending because it requires a coordinated second client. This PR does not claim that evidence.