Fix: Ban problematic orders instead of tokens on simulation failures

[anxolin]

Disclaimer: I implemented this feature mostly using claude, so please carefully review. The logic fills good now to me. Also, feel free to take ownership of this PR and apply commits on top.

Problem

The current metrics-based bad token detection incorrectly bans entire tokens when settlement simulations fail, even though failures are often caused by solver-specific issues, not the tokens themselves. This leads to legitimate tokens like
WETH or USDC being banned (for specific colocated solvers).

Example scenario:

• A solution with WETH→USDC + DAI→USDT fails due to a: solver routing bug, flashloan reverting, hook failing, other reasons
• All 4 tokens (WETH, USDC, DAI, USDT) get failure marks
• Eventually, good tokens get banned

Settlement simulations can fail for many reasons unrelated to token quality:

• Solver bugs
• Slippage issues
• Insufficient solver balance
• RPC/infrastructure errors
• Invalid solution encoding

Solution

Implement order-level banning with metrics-based detection tracking failures per order UID instead of per token.

Changes

• New bad_orders module mirroring bad_tokens structure
• Added order_uids() to solutions for tracking
• Modified encoding flow to track both tokens and orders
• New configuration options for order-level banning
• Added bad_orders_detected Prometheus metric

Configuration

[solver.my-solver]
enable-metrics-bad-order-detection = true
metrics-bad-order-detection-failure-ratio = 0.9
metrics-bad-order-detection-required-measurements = 5
metrics-bad-order-detection-order-freeze-time = "1h"

Note: Simulation-based bad token detection (which directly tests token behavior) remains unchanged and continues to work correctly.

Caveats

I think this PR improves things, preventing to blame tokens for an issue with a specific order. We can have now a similar issue with one problematic order making some other order to be banned because they are part of the same solution.

In practice, this affects only to one solver (is done in the driver), and I don't think will happen often. However, future PRs could enhance the granularity and try to simulate things in isolation if possible to find the culpit of reverts. Never the less, this should be way less intrusive and give fewer false positives than the old check.

Test

cargo test --package driver bad_orders

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[anxolin]

I have read the CLA Document and I hereby sign the CLA

[squadgazzz]

The order needs to be dropped from this cache once it is executed. We shouldn't accumulate all the failed orders here indefinitely.

[squadgazzz]

And we shouldn't accumulate successful orders here for sure.