Multi-account support for transaction submission

## Summary

Support submitting blobs from multiple funded accounts to avoid nonce contention when writing to a single namespace at high throughput.

## Problem

When a single account submits transactions concurrently, nonce (sequence number) conflicts cause failures:
- Tx A gets nonce 5, Tx B gets nonce 5 → one fails with "account sequence mismatch"
- Serial submission avoids this but kills throughput
- Mempool ordering is not guaranteed, so even sequential nonce assignment can race

## Design

### Account pool
- Configure multiple funded accounts (key/mnemonic per account)
- Round-robin or least-recently-used assignment when a submission is requested
- Each account manages its own nonce sequence independently

### Nonce management
- Track pending nonce per account locally (don't rely solely on on-chain query)
- Increment optimistically on broadcast, roll back on rejection
- Handle sequence mismatch errors by re-querying and retrying from the correct nonce

### Configuration
```toml
[submission]
enabled = true

[[submission.accounts]]
name = "submitter-1"
key_file = "./keys/submitter-1.json"

[[submission.accounts]]
name = "submitter-2"
key_file = "./keys/submitter-2.json"

[submission.pool]
strategy = "round-robin" # or "least-pending"
max_pending_per_account = 4
```

### Safety
- Monitor account balances, alert when low
- Cap max pending transactions per account to bound risk
- Graceful degradation: if an account is unhealthy (repeated failures, low balance), remove from rotation

## Dependencies

- Requires #4 (custom transaction submission client) — nonce management is tightly coupled with how we build and broadcast transactions

## References

- Cosmos SDK sequence/nonce model: `auth` module `BaseAccount.Sequence`