Allow internalizing sending transactions

[ty-everett]

Summary

• allow internalizeAction merge targets that are already in the sending state
• keep sending transactions in the normal broadcast/proof lifecycle instead of promoting them
• add a same-wallet payment regression for internalizing before monitor completion

Security / settlement semantics

• This does not treat arbitrary remote-provided transactions as settled. internalizeAction still validates the AtomicBEEF and txid before storage mutation.
• The new sending path is only a merge into an existing same-user transaction record that Storage already knows by txid.
• The transaction remains sending; it is not promoted to unproven or completed, and the existing monitor/posting flow remains responsible for advancing or failing it.
• Normal undelayed createAction funding excludes sending outputs. Delayed/chained flows can include sending outputs by design, matching the existing pending-chain policy.
• The current SDK result type only exposes accepted: true, so callers should interpret this as "accepted into wallet/storage state," not network settlement. A future API improvement should expose pending vs settled status explicitly.

Validation

• pnpm --filter @bsv/wallet-toolbox exec jest src/storage/__test/WalletStorageManager.test.ts --runInBand --testPathIgnorePatterns=man.test.ts
• pnpm --filter @bsv/wallet-toolbox run build
• git diff --check origin/main..HEAD

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud