Keyring and signing for transaction submission

[tac0turtle]

Summary

Implement key management and transaction signing for apex's blob submission path.

Context

Parent: #4

Apex needs to sign MsgPayForBlobs transactions. We need to decide on key storage and signing approach, then implement it.

Options

Option A: Direct key file (recommended for v1)

• Load a private key from an encrypted file on disk
• Sign with secp256k1 directly
• Minimal dependencies — no cosmos-sdk keyring needed
• Config:

  [submission]
  key_file = "./keys/submitter.json"
  key_password_env = "APEX_KEY_PASSWORD"  # env var for decryption

Option B: Cosmos SDK keyring

• Use cosmos-sdk/crypto/keyring with configurable backend (file, os, test)
• Battle-tested, supports multiple keys natively
• Heavier dependency, pulls in cosmos-sdk keyring packages
• Better fit if multi-account (Multi-account support for transaction submission #5) needs flexible key management

Option C: Remote signer (future)

• KMS integration (AWS KMS, HashiCorp Vault)
• Only if production security requirements demand it

Requirements

Regardless of approach:

• Sign MsgPayForBlobs with SIGN_MODE_DIRECT
• Derive account address from public key
• Support key rotation without downtime (reload on SIGHUP or config change)
• Never log or expose private key material
• Key file must not be committed to git (.gitignore the keys directory)

Interaction with multi-account (#5)

If multi-account support is enabled, the keyring must manage N keys. Option B becomes more natural in that case. Consider starting with Option A for single-account and migrating to Option B when #5 is implemented.

References

• cosmos-sdk/crypto/keyring — standard Cosmos keyring
• cosmos-sdk/crypto/keys/secp256k1 — direct key operations
• celestia-node nodebuilder/state/keyring.go — their keyring setup (reference, not to reuse)