zcash_pool_migration: Let a signer's capacity size one run

[dannywillems]

Stacked on #2962 (base dw/pool-migration-note-cap); review that one first.

The problem

A per-run note cap cannot bound what an external signer is asked to sign in one
interaction. A run's signing workload is 16 * preparations + 3 * transfers,
and the preparation count follows the wallet's FRAGMENTATION rather than the
number of notes the run mints. So one cap gives one wallet a single-round run
and another a four-round run, and a Keystone user sees several QR signing rounds
inside what the UI presents as one migration run.

signing_round_count(budget) already reports that after the fact. Nothing could
ask for it in advance.

The change

signing_rounds::RunSigningCapacity states the bound a device actually has —
actions per interaction, interactions per run, and a note ceiling never to
exceed — and signing_rounds::largest_run_size_within turns it into a note cap
by searching for the largest run that fits.

That search is the inverse of the round count in the run SIZE, as the existing
min_budget_for_rounds is its inverse in the BUDGET; the two now sit together.
It probes the sizing oracle logarithmically (once when the whole run already
fits) and only ever returns a cap a probe accepted, so an arbitrary preparation
portfolio still gets a run that fits even where the round count is not monotone
in the cap. Under monotonicity — what the canonical decomposition gives, since
raising the cap extends the split rather than reshaping it — the two are adjoint
and the chosen cap is the largest run the signer signs.

The one case no sizing can fix is a wallet fragmented enough that minting even a
single funding note overflows a round. The run is planned anyway and the
overflow stays visible in MigrationPlan::signing_round_count.

API

Both bounds are first-class and nothing existing changes shape:

entry point	bound
plan_migration	default note cap (unchanged)
plan_migration_with(portfolio, max_notes, ..)	note count (unchanged signature)
plan_migration_for_signer(capacity, ..)	signer capacity
plan_migration_for_signer_with(portfolio, capacity, ..)	signer capacity + portfolio
plan_migration_sized_with(portfolio, sizing, ..)	either, as a RunSizing value

estimate_migration_runs* mirrors all five. Sizing is per run, over the note
structure that run starts from, so the preview describes the runs the planner
will build: a wallet migrates fewer notes in the runs that consolidate its
fragmentation and more once its notes are larger.

RunSizing is public so an application that lets the user choose between the
two bounds can carry that choice as a value.

Testing

cargo test -p zcash_pool_migration --all-features (284 unit + every
integration test), cargo fmt --check, cargo clippy --all-features --all-targets -D warnings, cargo check --workspace --all-features and
--no-default-features, all clean.

The search's unit tests hold it to the adjunction against an explicit oracle and
to feasibility against a deliberately non-monotone one. tests/signer_capacity.rs
drives the wallet-facing API from outside the crate: the scenarios that need
several Keystone rounds under the note cap plan in one round when sized for the
signer, the signer-sized plan is exactly the note-capped plan at the chosen cap
(so sizing only picks a cap, it never reshapes a run), one entry point reaches
either bound, and every run the estimate forecasts is one signing round.

🤖 Generated with Claude Code

The base branch was changed.