feat: support `--file` flag for binary data in `dot tx`

Context

Some Substrate extrinsics accept binary data (e.g., TransactionStorage.store({ data: chunk_bytes })). Currently, the only way to pass binary data is as a hex string argument on the command line. For large data (images, videos, evidence files), this is impractical:

• Command line length limits
• Manual hex encoding of files
• No chunking support for data that exceeds single-extrinsic limits

Example use case: Proof of Ink evidence upload requires splitting a photo/video into chunks and submitting each as a TransactionStorage.store() call on the Bulletin chain.

Proposal

Add a --file flag to dot tx that reads binary data from a file and uses it as an extrinsic argument:

Basic Usage

# Read file as bytes and pass to the data argument
dot tx TransactionStorage.store --file ./evidence.jpg --from candidate --chain bulletin

Chunked Upload

For data that exceeds a single extrinsic's capacity, support automatic chunking:

# Split file into 64KB chunks and submit each as a separate transaction
dot tx TransactionStorage.store --file ./video.mp4 --chunk-size 65536 --from candidate --chain bulletin

Output for chunked mode:

Uploading ./video.mp4 (2.1 MB) in 33 chunks of 64 KB...
Chunk  1/33: 0xabc123... (finalized in #1234)
Chunk  2/33: 0xdef456... (finalized in #1235)
...
Chunk 33/33: 0x789012... (finalized in #1266)

Upload complete. 33 transactions finalized.

With --output json:

{
  "file": "./video.mp4",
  "totalBytes": 2100000,
  "chunks": 33,
  "chunkSize": 65536,
  "transactions": [
    { "chunk": 1, "txHash": "0xabc...", "block": 1234 },
    ...
  ]
}

Design Considerations

Which argument gets the file data?

Option A: Auto-detect the Sequence<u8> / Vec<u8> argument in the call signature and inject the file bytes there.

Option B: Explicit positional mapping: dot tx TransactionStorage.store --file data:./evidence.jpg where data is the argument name.

Recommendation: Option A for calls with a single bytes argument (common case). Option B as fallback.

Chunking Strategy

• Default chunk size based on chain's max extrinsic size (queryable from metadata constants)
• --chunk-size <bytes> for explicit override
• Sequential submission with nonce management (wait for each to be included, or batch with nonce offsets)
• Resume support: --resume flag that checks which chunks are already stored (optional, future enhancement)

Error Handling

• If any chunk fails: report which chunk failed, allow retry from that chunk
• If fee estimation fails: report estimated cost for full upload before starting
• Dry-run support: --dry-run to show chunk count and estimated total fees without submitting

Implementation Notes

• Use Bun.file() for reading (per CLAUDE.md conventions)
• For chunking: split Uint8Array into fixed-size segments
• Each chunk becomes a separate dot tx TransactionStorage.store call
• Progressive output with per-chunk status tracking
• Consider a manifest/summary output that can be used in subsequent steps

Why This Matters for Agent Workflows

The DIM1 Proof of Ink runbook (Step F) requires:

1. Reading a media file (photo/video)
2. Splitting into chunks
3. Submitting each chunk to Bulletin chain
4. Submitting an instruction manifest
5. Computing hash of the manifest

Steps 1-4 are currently impossible with the CLI alone. This feature would make the entire upload workflow possible within dot commands.

Labels

enhancement, agent-readiness

Start with the dot tx entry point and read CLAUDE.md for the Bun file-reading conventions. Determine how TransactionStorage.store arguments are resolved before choosing between automatic bytes-argument detection and explicit mapping. Done means file input works, chunked uploads and their progress or JSON summaries are handled, and the proposed error, dry-run, and nonce behavior is covered.