e2e test that we drop vol. fee on ethflow native bridging order

[extrawurst]

As a followup to #4531.

This adds a bit to our ethflow native bridging test to regression proof us dropping the volume fee on these type of trades.

for context see slack

[claude]

Claude finished @extrawurst's task in 4m 2s —— View job

---

PR Review: e2e test that we drop vol. fee on ethflow native bridging order

• Read PR diff and context
• Review the test changes
• Post inline comments for issues
• Post review summary

This is a clean, well-targeted addition. It extends the existing ethflow native-bridge test to assert no volume fee is charged on a WETH → native-ETH (same-token) order, on both the quote (protocol_fee_bps.is_none()) and the settlement (executed_protocol_fees.is_empty()).

What I verified:

• Types/config wiring — FeePoliciesConfig (autopilot) + VolumeFeeConfig (orderbook) are constructed correctly; FeeFactor accepts both try_into() and new(0.01). The default enable_sell_equals_buy_volume_fee = false is what makes the drop the expected behavior.
• Mechanism is real — is_same_buy_and_sell_token normalizes BUY_ETH_ADDRESS to the native token, so WETH→native-ETH is correctly detected as same-token (already unit-tested in shared/src/fee.rs).
• Settle/read ordering — waiting on non-zero executed_fee before reading executed_protocol_fees matches the established pattern in protocol_fee.rs; the uid(...)/get_trades(...) usage is consistent with the rest of the file.

One optional, non-blocking note posted inline: the test only asserts the absence of a fee, with no in-test positive control proving the fee would otherwise apply on this path (the ethflow order is Limit-class only because fee_amount == 0). Risk is low given the existing volume_fee_dropped_on_same_token test and the shared unit tests already cover the positive side — see the inline comment for the suggestion.

No bugs or blocking issues found.

[gemini-code-assist]

Code Review

This pull request updates the end-to-end ethflow tests to configure and verify that volume fees are not charged for same-token trades (specifically WETH to native ETH) on both quotes and settlements. No critical issues were found in these changes.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[claude]

Both assertions here (and the quote one above) check the absence of a fee, but nothing in this test proves the configured volume fee would otherwise apply on the ethflow path. If the wiring ever silently stopped charging the fee for an unrelated reason, this test would keep passing without exercising the same-token drop it's meant to guard.

Concretely, the volume policy only applies to OrderClass::Limit orders (autopilot/src/domain/fee/policy.rs:92-104), and the ethflow order is classified Limit only because its fee_amount is zero (onchain_order_events/mod.rs:627-630). So the drop being tested is one of two reasons the fee could be absent.

This is a low risk in practice — volume_fee_dropped_on_same_token in protocol_fee.rs already pairs the same-token drop with a different-token positive control, and the underlying get_applicable_volume_fee_factor is unit-tested for BUY_ETH_ADDRESS. So I'd treat this as optional, but a one-line note pointing at the existing positive-control test (or a brief comment that the Limit classification is what makes this non-vacuous) would make the regression intent more robust to future changes.

[squadgazzz]

LGTM