[alpinskiy-top]

PrepareMigration threw away everything it had built when the source wallet could not cover the transfer gas, so a client that only lacked TON had to re-request prepare after topping up. The transactions are buildable in that case: emulation already runs against a synthetically over-funded balance.

Both shortfall checks — the static plan minimum and the post-emulation spend — now fold into one observation instead of returning early, the loop builds and emulates every batch, and the shortfall is reported at the end on a body that also carries from/to/wallet_version/transactions. worseShortfall keeps the larger of the two requirements so the client is not told to top up twice.

The 409 body is a new MigrationPrepareConflict schema (allOf of MigrationPrepareResponse plus the error properties); the shared error response is untouched. Two status codes cannot share one schema: ogen dedups response types by name over a Go map, so the encoder would emit a single case whose status code flips between regenerations. This makes prepareMigration the first operation with two concrete responses, hence the PrepareMigrationRes sum type and the client signature change.

Three cases the deferral has to respect:

• the pre-sweep deduction is skipped on a shortfall, because the wallet has by then spent into the over-funding and deductGramBalance would fail its balance check, turning the 409 into a 500;
• the sweep batch's spend delta is not measured, since it spends the over-funding too and would report a wildly inflated required;
• an uninitialized source cannot be over-funded, so it keeps the early return, and a later failure degrades to the bare shortfall rather than masking it or handing out a truncated, out-of-order plan.