[indexer]: track fill userop hashes, actual delivered amounts, and placeOrder fee token

[seunlanlege]

Closes #1104.

Adds the three missing pieces of IntentGatewayV3 data to the indexer: the userop hash behind each fill, the amount the beneficiary actually received, and the token placeOrder fees are denominated in.

Schema

Entity	Field	Notes
IOrderV3Fill, IOrderV3PartialFill	userOpHash: String	nullable — null for EOA fills
IOrderV3FillOutputAsset, IOrderV3PartialFillOutputAsset	amountReceived: BigInt	nullable — null for native outputs
IOrderV3	feeToken: String!, feeTokenDecimals: Int!	derived from the host contract

All additions are nullable or derivable, so no reindex-incompatible change.

Userop hash

Solvers fill through the ERC-4337 SolverAccount, so the stored transactionHash is the bundler's EntryPoint transaction, not the userop the solver submitted and tracks. The fill handlers now read the fill transaction's receipt and take the userOpHash from the first UserOperationEvent after the fill log whose sender is the filler. The EntryPoint emits that event once an op finishes executing, so within a bundle containing several solvers' ops the sender match plus the log-index ordering picks the right one. Plain EOA fills emit no such event and leave the field null.

Amount received

ExtrinsicIntents.fill() emits outputFills[i].amount = totalRequired — the order's promised amount (ExtrinsicIntents.sol:134). On an overfill the beneficiary receives totalRequired + beneficiaryShare from the surplus split, and the solver's actual solverAmount never appears in the event. Since the solver transfers output assets directly to the user, amountReceived comes from the Transfer logs (filler → beneficiary) in the fill receipt.

Two cases the matching handles:

• Batched fills. A solver can fill several orders in one transaction. Transfers are only considered between the preceding OrderFilled/PartialFill log and this one, so each delivery is attributed to the fill it belongs to. Repeated tokens within one fill consume their transfers in log order.
• Unindexed orders. Matching needs the beneficiary, normally read from the indexed order. Cross-chain fills are indexed on the destination chain independently of the source chain that placed the order, so the order may not exist yet. In that case the order is recovered from the fill transaction's calldata (direct or nested, via the call tracer) and accepted only if its recomputed commitment matches the event's — which also disambiguates when one transaction carries several fillOrder calls.

Native-token outputs emit no Transfer log, so they stay null rather than being guessed.

Fee token

Fees are paid in the host's fee token (IDispatcher(host()).feeToken()), which differs per chain, so IOrderV3.fees couldn't be displayed or priced without hardcoded per-chain knowledge. orderPlacedV3 now reads it from the host contract resolved through CHAINS_BY_ISMP_HOST, along with the token's decimals so fees renders without a second lookup. Both are static per chain and cached together per chain rather than fetched per order.

Tests

13 unit tests in src/utils/__tests__/fill.helpers.test.ts cover userop-hash selection (sender mismatch, events before the fill, EOA fills), transfer matching (overfill, repeated tokens, native outputs, wrong-direction and protocol-share transfers, batched fills), and fillOrder calldata decoding.

The indexer build (ENV=mainnet npm run build:release, including schema codegen) passes. The three failing suites in the wider run — state-commitment, phantom-decode, bridgeTokenSupply — fail identically on a clean tree; they hit live networks.

[Wizdave97]

@royvardhan for this PR we'll need to modify subquery to allow us add new fields to schema entities, please look into it.