feat(transactions): dry_run preview for bulk and inflight

[Shivam8584]

Completes #330 by adding dry_run to POST /transactions/bulk and PUT /transactions/inflight/:txID.

Stacked on #348 — please merge that first; this branch contains its three commits, so the diff here is just the final commit. Rebases to main cleanly once #348 lands.

Bulk: the projection mode has to match how the batch really runs

This is the part the original issue got wrong, and it's the main reason this is a separate PR.

I'd claimed later items see earlier items' balance changes. That's only true with skip_queue: true. processBulkTransactions assigns the batch-level flag to every item (transaction_bulk.go:36), so on the default path each item goes to processTransactionAsync's detached goroutine and the loop moves on — the items race.

So the mode follows the flag, and the response says which one you got:

// skip_queue: true — 500.00 available, items of 450.00 then 100.00
{ "cumulative": true, "would_apply": false,
  "results": [ { "would_apply": true },
               { "would_apply": false, "rejection": { "code": "TXN_INSUFFICIENT_FUNDS" } } ] }

// skip_queue: false — same input, both fit on their own
{ "cumulative": false, "would_apply": true,
  "results": [ { "would_apply": true }, { "would_apply": true } ] }

Identical input, opposite verdict, because the execution semantics genuinely differ. Projecting cumulatively on the default path would assert an ordering the ledger doesn't provide — an authoritative-looking wrong answer, which is worse than no preview.

Batch-level balances are reported only in cumulative mode: without a guaranteed order there's no single combined outcome to state.

No all_or_nothing field, for the same honesty reason. rollbackBatchTransactions compensates by voiding or refunding already-applied items after a failure, and that compensation can itself fail. The response carries a note saying so rather than implying isolation.

Balances are fetched once per distinct balance and reused across items — needed for correctness in cumulative mode anyway, and it keeps a 10k-item batch from doing 20k round trips.

Inflight: reuses the existing expansion rather than reimplementing it

preValidateInflightAction already handles the case where an id names the parent of a split rather than a single hold, so the projection resolves legs the same way and projects every leg — a per-transaction preview on a parent would otherwise answer for one representative leg, or fail outright.

Void has no partial form: finalizeVoidTransaction always uses the full remaining hold. An amount sent with a void is reported as ignored rather than silently dropped:

PUT /transactions/inflight/:id  { "dry_run": true, "status": "void", "precise_amount": 4000 }

{ "operation": "void", "precise_amount": "10000",
  "notes": ["amount is ignored when voiding; a void always releases the full remaining hold"] }

Both projections run on clones — validateAndUpdateAmount writes the settled amount onto the transaction it's given. The dry-run branch also sits ahead of ApplyPrecisionWithDBLookup, which caches into package-level state.

Tests

9 new tests covering: cumulative mode catching an intra-batch shortfall; independent mode not assuming order; batch and inflight previews writing nothing (balances and version unchanged, hold still INFLIGHT, no settlement rows); void ignoring its amount; and unsupported actions still being rejected as malformed.

Verified against a running server — the cumulative case correctly rejected the second item at TXN_INSUFFICIENT_FUNDS where independent mode passed both, the commit projection showed the hold releasing and the money moving while void showed the hold releasing with the balance unchanged, and afterwards the hold was still INFLIGHT with zero settlement rows written.

go test ./... passes apart from internal/search, which needs Typesense and fails identically on main.