Represent accepted transactions with pending hashes

[csmithington]

Summary

Transaction submission can be durably accepted before a broadcast hash is available. This pins that state across all public consumers instead of turning it into a server or client error.

• return HTTP 200 with a present hash: null for an accepted/pending submission
• retain a known hash as a string when it is already available
• model the Rust hash as Option<TransactionHash> and TypeScript as `0x${string}` | null
• make the TypeScript EIP-1193 provider poll the accepted transaction by ID before returning a hash-dependent result
• expose waitForTransactionHashById, render <pending> in the CLI, and tell other clients to poll by transaction ID
• cover direct and random response JSON, known/pending hashes, CLI output, SDK type/runtime contracts, and e2e consumers
• add an upstream TypeScript SDK CI job so the runtime polling scenario is enforced

Validation

• cargo fmt --all -- --check
• cargo clippy -- -D warnings -A clippy::uninlined_format_args
• cargo test --exclude rust-sdk-playground --workspace
• npm test in sdk/typescript (build plus three accepted-hash runtime scenarios)
• npm run build in documentation/rrelayer

No FIET-specific configuration or downstream governance files are included.

[vercel]

@csmithington is attempting to deploy a commit to the joshaavecom's projects Team on Vercel.

A member of the Team first needs to authorize it.