orders/immediate scans the whole order book (O(book)); needs an asset-pair index

`orders/immediate` matching iterates every order under the store prefix to find asset-compatible counterparties (`x/orders/transactions/immediate/transaction_keeper.go`). The recent fix added early termination once the collected counterparties can fill the incoming order, so the common fillable case is bounded, but an unfillable or thin-book order still scans the entire book, and store reads are gas-metered — an attacker who grows the book raises the cost of every immediate order and can push it past the block gas limit (liveness).

The root cause is that orders are keyed only by their hash, with no secondary index by (makerAsset, takerAsset) pair, so "find counterparties for pair X/Y" cannot be a prefix scan.

## Proposed fix
Add a secondary index keyed by the asset pair (and ideally price) so matching iterates only the relevant book side. Larger change; deferred behind the correctness fixes.

## Fix-priority scorecard

| SEC | UX | AUTO | YAGNI | DELTA | FIN |
|-----|----|------|-------|-------|-----|
| 50 | 40 | 30 | 35 | 25 | 37 |

Start in x/orders/transactions/immediate/transaction_keeper.go and trace how orders are keyed and how counterparties are scanned under the store prefix. Investigate the store's indexing and iteration constraints, then define the asset-pair (and, if appropriate, price) index so matching reads only the relevant book side. Done means unfillable and thin-book immediate orders no longer scan the entire order book.

Written by the indexing model from the issue text.