fix: revert on exact-output partial fills in V4Router

[ccashwell]

Summary

A v4 exact-output swap can partial-fill: _swap hard-codes sqrtPriceLimit to the global min/max bound (MIN_SQRT_PRICE + 1 / MAX_SQRT_PRICE - 1), so when a pool runs out of liquidity across the tick range the swap stops at the limit having delivered less than the requested amountOut. V4Router's exact-output paths only bound the input (amountInMaximum) and never check the realized output, so an under-filled exact-output swap silently succeeds with a short delivery — the opposite of "exact output."

This also distorted the per-hop price guard (#516): priceX36 was computed from the requested amountOut over the actual amountIn, overstating the execution price, so on a partial fill a swap could pass minHopPriceX36 at a realized price below the caller's bound.

Fix

Make exact output all-or-nothing in V4Router:

• _swap now returns the full BalanceDelta; two pure helpers (_swapInput / _swapOutput) extract the realized input/output, preserving the prior reciprocal extraction exactly.
• _swapExactOutputSingle and _swapExactOutput (per hop) assert the realized output covers the requested amount and revert a new V4ExactOutputUnfilled(amountOutRequested, amountOutReceived) on a shortfall.
• The per-hop price guard now prices the realized output.

Behavior:

• Exact-input is unchanged (it already checked delivery via amountOutMinimum and priced on realized output).
• Full fills are unaffected — a fully-filled exact-output swap delivers exactly amountOut, so the check is a no-op for them (verified: all existing exact-output router tests pass unchanged).
• The check is realizedOut < amountOut (revert on shortfall), not strict !=, so over-delivery is allowed — it can only arise via hook pools, is harmless (amountInMaximum still bounds cost), and reverting on it would be hostile.

Design decision for reviewers (hook pools)

This changes canonical exact-output semantics for every integrator, so it warrants a thorough review of the behavior changes. The one substantive concern is hook pools: a hook with a BeforeSwapDelta/afterSwapDelta can legitimately make the realized output differ from the requested amount. Under this change, a hook that delivers less than requested on an exact-output swap would now revert. This is defensible because the caller asked for an exact amount and the pool didn't provide it, but it is a behavior change such pools would observe.

Two questions we should agree on before merging this:

1. Is revert-on-shortfall the desired canonical behavior for exact output, or should hook pools be exempt / opt-out?
2. realizedOut < amountOut (allow over-delivery) vs strict realizedOut != amountOut (literal "exact"). This PR uses the former, but I'm not 100% on whether this is the right call.

Context

Surfaced while integrating V4Router in a margin-trading periphery (#563), where exact-output is used to size leverage opens. That PR guards the gap at the application layer (an ASSERT_FILL / IncompleteFill check before using the swap output). This PR is the proper root fix in the shared router; if it lands, the app-layer guard becomes redundant defense-in-depth.