feat: transaction history and replay for `dot tx`

Context

When working with Substrate chains, certain extrinsics need to be re-submitted periodically or on-demand — for example, recurring governance votes, periodic maintenance calls, or repeating a workflow across different signers. Currently, there's no way to recall and re-execute a previously sent transaction without manually re-typing the full command.

Problem

• No history of previously submitted extrinsics
• Re-running a past transaction requires remembering the exact call, args, and chain
• Switching the signer for a known transaction requires rebuilding the command from scratch
• Recurring workflows (e.g., "run this transfer every week") have no shortcut

Proposal

Add transaction history tracking and replay capabilities to dot tx:

Automatic History

Every successfully submitted extrinsic is logged locally:

# Show recent transaction history
dot tx --history

# Output:
#  [1] 2026-02-25 Balances.transferKeepAlive (polkadot) --from alice
#  [2] 2026-02-24 Staking.nominate (polkadot) --from validator
#  [3] 2026-02-20 ProofOfInk.apply (people) --from candidate

Replay

Re-submit a previous transaction, optionally with a different signer:

# Replay transaction #1 with the same signer
dot tx --replay 1

# Replay transaction #3 with a different signer
dot tx --replay 3 --from other-account

Named Bookmarks / Catalog

Save frequently used extrinsics with a name for easy recall:

# Save a transaction as a named bookmark
dot tx Balances.transferKeepAlive --args '...' --chain polkadot --save-as "weekly-transfer"

# Run a saved transaction
dot tx --run weekly-transfer

# Run with a different signer
dot tx --run weekly-transfer --from bob

# List saved transactions
dot tx --catalog

Design Considerations

• Storage: History and bookmarks stored locally (e.g., ~/.dot/history.json and ~/.dot/catalog.json, or in an XDG-compliant config dir)
• What to store: call name, args, chain, original signer, timestamp, tx hash, block number
• Privacy: Local-only, no sensitive data (seeds/keys are never stored, only signer alias names)
• Signer override: --from on replay/run should override the original signer
• Arg override: Consider allowing partial arg overrides on replay (future enhancement)

Relationship to Other Issues

• #5 (--batch): A saved catalog entry could be exported to a batch file, or a batch file could be saved as a named workflow. The --emit-batch idea from #5 feeds naturally into this — you could --save-as a batch file as a reusable workflow.
• The history/catalog is complementary to batch mode: batch is for multi-tx workflows, history/catalog is for single-tx recall and replay.

Example Workflow

# First time: submit and save
dot tx Staking.nominate '[validator1, validator2]' --chain polkadot --from stash --save-as "nominate-validators"

# Later: re-run the same nomination
dot tx --run nominate-validators

# Even later: run it from a different stash
dot tx --run nominate-validators --from other-stash

Labels

enhancement

Start by locating the existing dot tx command entry point and reviewing how submitted extrinsics are represented. Use the proposed local history and catalog paths as the storage boundary, then define the scope for recording successful submissions, listing them, replaying them, and running named entries with signer overrides. Done means the command behavior and storage format are specified and covered for those workflows.