match_orders compares inverted prices, accepting fills worse than the incoming limit

### Summary

`match_orders()` compares the existing order price directly against the incoming order price even though the two orders have inverse source/target assets. That means the comparison uses mismatched units and can accept fills that are worse than the incoming order's limit.

### Code path

`backend/order-book/src/order.rs`:

```rust
if existing_order.price() > incoming_order.price() {
return Err(OrderError::PriceTooHigh(...));
}
```

`Order::price()` returns `target_asset_amount / source_asset_amount`. For a resting order that matches an incoming order, the assets are reversed, so the resting order's price is denominated in the inverse unit.

### Example

The current test fixture already shows this case. The incoming order offers 10 source for 20 target, so its limit is 2 target per source. A resting order with 5 target as source and 10 source as target asks for 2 source per target, which is worse than the incoming limit of 0.5 source per target.

The current direct comparison sees `2.0 > 2.0` and accepts the fill, even though the prices are not in the same unit.

### Expected behavior

The match check should compare prices in the same unit, preferably with integer cross-multiplication to avoid floating point rounding. A resting order should be rejected when it asks for more incoming source per incoming target than the incoming order allows.

The bug is in `backend/order-book/src/order.rs` in the `match_orders()` function. Start by understanding the `Order::price()` method and how source/target assets are defined for resting vs. incoming orders. The fix involves comparing prices in the same unit, likely using integer cross-multiplication. Look at existing tests to see the failing case and verify the fix.

Written by the indexing model from the issue text.