Reliability: RocksDB request updates are read-modify-write without transactions

## Summary

`Storage::update_request_status`, `update_request_tx_hash`, and related paths load a request, mutate it in memory, and write it back (`src/storage.rs`). There is no optimistic locking or RocksDB transaction.

## Risk

Concurrent tasks (for example JSON-RPC handler vs. background receipt poller vs. gas-bump loop) can interleave such that **one writer overwrites another’s fields** (lost status transition, dropped `transaction_hash`, or inconsistent `task_id` index vs. row). Under load or slow RPC this becomes more likely.

## Suggested mitigations

- Use a single-writer queue per request id, or RocksDB transactions / merge operator.
- At minimum, compare-and-swap on a monotonic `version` field stored with each request.

## References

- `src/storage.rs` (`update_request_status`, `store_request`)