Extract a standalone Rust transaction builder crate from the CLI

Start by reading tx/builder/transaction.rs and the surrounding tx/builder helpers, then compare assembled.rs and signer/ with the CLI-coupled code under commands/tx/new/. Define the standalone crate boundaries and API against the listed SDK prior art; done means the crate provides the proposed building, signing, assembly, and operation helpers without CLI concerns and the CLI can consume it incrementally.

Summary

Every Stellar SDK (Python, JS, Java, Go) provides a high-level TransactionBuilder for constructing, signing, and submitting transactions. Rust has no equivalent — developers must work directly with stellar-xdr types, which is low-level and error-prone.

The CLI already contains transaction-building logic (builder traits, operation construction, signing, simulation/assembly), but it's tightly coupled to CLI concerns (clap, config, printing). Extracting this into a standalone crate would fill the gap and give Rust developers a first-class transaction building experience.

What exists today in the CLI

• TxExt trait for building transactions (tx/builder/transaction.rs) — already has no CLI dependencies
• Amount and Asset helpers (tx/builder/)
• Assembled struct for post-simulation transactions (assembled.rs) — depends only on stellar-xdr + soroban-rpc
• Signer abstraction with local key, Ledger, Lab, and secure store backends (signer/)
• 23 operation builders (commands/tx/new/) — currently coupled to clap/config
• Soroban authorization signing — mostly pure crypto

Proposed scope

A new workspace crate (e.g. cmd/crates/stellar-transaction-builder/) providing:

• TransactionBuilder with a fluent API matching other SDKs: source account, fee, sequence number, operations, memo, preconditions, build()
• Operation helper functions for all 23 operation types (pure functions: XDR types in, OperationBody out)
• TransactionSigner trait decoupled from CLI printing/config
• Assembled transaction wrapper and simulation support (feature-gated behind rpc)
• Soroban auth signing utilities

What stays in the CLI

• sim_sign_and_send_tx orchestrator (caching, printing, explorer URLs)
• clap argument parsing and config/address resolution
• User interaction (prompts, confirmations)

Prior art

• Python: stellar_sdk.TransactionBuilder — fluent method chaining, 60+ operation append methods
• JS: StellarSdk.TransactionBuilder — constructor with options, addOperation(), build()
• Java: org.stellar.sdk.TransactionBuilder — builder pattern with method chaining
• Go: txnbuild.NewTransaction(TransactionParams{...}) — struct-based params with operation array

All follow the same separation: building (pure) → simulation (async) → signing (crypto) → submission (async).

Suggested approach

1. Create the new crate alongside existing code (no breaking changes to CLI)
2. Migrate CLI to consume the new crate incrementally
3. stellar-ledger already demonstrates this extraction pattern successfully