Tests cover bps/pct conversion, display formatting edge cases, and
order book VWAP slippage computation for both long/short directions
including insufficient liquidity and invalid data handling.

- Add MAX_SLIPPAGE_BOUNDS constant to perpsConfig.ts (MinBps/MaxBps/StepBps)
- Use MAX_SLIPPAGE_BOUNDS in setMaxSlippage() instead of magic numbers
- Derive UI-side slippageConfig.ts bounds from shared constant
- Remove unused MAX_SLIPPAGE_SOURCE and ESTIMATED_SLIPPAGE_PCT event properties

- Empty order book side now correctly returns insufficientLiquidity: true
  instead of EMPTY_RESULT (which had insufficientLiquidity: false)
- Removed custom memo comparator from PerpsSlippageBottomSheet that
  omitted onSave/onClose props, causing stale closure risk

Replace toBeTruthy() with toBeOnTheScreen() for element presence
assertions per project unit testing guidelines.

…nstants

Move the order-book level count and throttle window used by
`usePerpsEstimatedSlippage` into `PERFORMANCE_CONFIG`
(`SlippageEstimateBookLevels`, `SlippageEstimateThrottleMs`) so the
tuning sits alongside the other perps timing constants and matches the
anti-pattern guidance about avoiding inline magic numbers.

Round 1 cross-review from Codex and Claude flagged three actionable
gaps on the new estimated-slippage path. Resolve all three:

- Stop defaulting an unavailable estimate to `0` percent. When the L2
  order book has not produced data yet (or is too shallow to fill the
  requested size), the slippage row now renders `Est: -- / Max: X%`
  via a new `row_format_pending` i18n template and `estimatedSlippagePct`
  is kept nullable. The user-configured cap still flows to HyperLiquid
  as the limit-price buffer, so we surface "pending" without blocking
  the order — but the misleading `Est: 0%` placeholder is gone.
- Expose the displayed slippage value to agentic recipes by adding a
  dedicated `SLIPPAGE_VALUE` testID (`perps-order-view-slippage-value`)
  on the inner `<Text>` and registering it in `Perps.testIds.ts`.
- Add `slippageCalculation.test.ts` covering the VWAP walk for null
  books, missing/zero levels, shallow depth, exact and partial fills,
  buy/sell direction, and the non-negative clamp.

Also document why `usePerpsEstimatedSlippage` overrides the doc's 10s
order-form WS guideline with a 250ms throttle — slippage needs sub-
second updates while the user types, and the downstream `useMemo` keeps
per-tick work cheap.

Deferred nits:
- Adding `exceedsMaxSlippage` to the place-order button's `isDisabled`
  would suppress the `slippage_limit_blocked_order` analytics event,
  which the product team needs for the orders-blocked-by-slippage
  guardrail. Keeping the toast-on-tap path preserves that signal.
- Existing direct `PerpsController.get/setMaxSlippage` reads stay in the
  component to match the surrounding pattern in `PerpsOrderView`; moving
  them behind a hook is a broader refactor.

…eads

Round 2 cross-review flagged two real issues that this commit fixes:

- VWAP estimator walked the L2 book by quote notional, but the
  HyperLiquid provider executes a fixed base size derived from
  `usdValue / currentPrice`. The estimator now derives the same base
  target and walks levels by base size, so the bps figure matches the
  shape of the actual fill instead of underestimating buy slippage
  (and overestimating sell slippage). The unit tests now assert exact
  bps for both buy and sell two-level fills (`333.33` bps for the
  same `[100/110]` and `[100/90]` books at `$1500`), which is what
  caught the regression.
- New `usePerpsMaxSlippage` hook owns the controller reads/writes so
  `PerpsOrderView` no longer calls `Engine.context.PerpsController`
  directly. The hook returns the resolved bps value, the source
  (`default` vs `user_configured`), and a setter that refreshes the
  memoised read after a save. This addresses the anti-pattern doc's
  "Direct controller call from component" rule for the slippage path.

…im comments

Address Round 4 cross-review findings:

- Move the slippage block to the top of `handlePlaceOrder`, ahead of
  the trade-with-any-token deposit branch, so an excessive-slippage
  order never starts a deposit or signature flow before being rejected.
- Normalize the deprecated decimal `slippage` to bps before the
  position-size calc, not just before the limit-price calc, so the
  price-staleness check inside `calculateFinalPositionSize` uses the
  caller's cap instead of falling back to 300 bps.
- Format the estimated slippage row to two decimals so the value never
  renders as `3.333333%`.
- Refresh the VWAP helper JSDoc to match the new base-size walk.
- Strip ticket references (AC1/AC5/Jira) from inline comments; keep
  only short technical notes.
- Add a hook test for `usePerpsMaxSlippage` covering the default
  source, the user-configured source, and the persist+refresh path.

Replace the bare `10000` literal in the placeOrder/editOrder shim with
the existing `BASIS_POINTS_DIVISOR` import so the conversion matches
the convention used elsewhere in this file (USDH swap slippage,
builder-fee discount math).

…test

- Use `BASIS_POINTS_DIVISOR` in `calculateEstimatedSlippageBps` instead
  of a bare `10000` literal so the bps→decimal conversion matches the
  convention used by the HyperLiquid provider and the controller fee
  math.
- Format the `max` percent in the slippage-exceeds-max toast to two
  decimals (was unformatted while `est` already used `.toFixed(2)`).
- Source `PERPS_SLIPPAGE_DEFAULT_BPS` from
  `ORDER_SLIPPAGE_CONFIG.DefaultMarketSlippageBps` so the order screen
  default and the controller default cannot drift apart.
- Drop the unnecessary `rerender()` call from `usePerpsMaxSlippage`
  test (the type signature requires a props argument and `act` already
  flushes the state update).
- Add a `PerpsOrderView` component test that mocks an estimated
  slippage of 5% against a 1% cap, presses Place Order, and asserts
  `placeOrder` is not called while the validation-error toast fires.
  Covers the AC5 submit-block path that previously had no checked-in
  component coverage.

… nits

Resolves Round 8 cross-review findings:

- The new `PerpsOrderView` slippage-block test was failing when run as
  part of the full file because the surrounding suite mutates several
  shared mocks (`usePerpsOrderContext`, `usePerpsOrderValidation`, the
  slippage hooks). Restore each mock the block path reads in the new
  `beforeEach`, and tighten the assertion to the AC invariant — an
  excessive-slippage order must not reach `placeOrder`. The toast copy
  and analytics payload are covered by the agentic recipe and event
  constants.
- Use `BASIS_POINTS_DIVISOR` for the bps → decimal conversion in
  `calculateOrderPriceAndSize` instead of a bare `10000` literal, in
  line with the same change applied to the slippage estimator.
- Include `max_slippage_source` on the `slippage_config_changed`
  interaction event so the analytics payload matches the other
  slippage events.

- `usePerpsMaxSlippage` now reads `PERPS_SLIPPAGE_DEFAULT_BPS` from the
  UI's `slippageConfig` re-export so there is a single import path to
  the default value (the constant itself is sourced from the controller).
- Inline comment next to the existing `eslint-disable-next-line
  react-hooks/exhaustive-deps` so the intent (revision counter forces
  re-read of `Engine.context`) is visible without scrolling.
- Add a `HyperLiquidProvider.placeOrder` regression test that exercises
  the deprecated decimal `slippage: 0.02` shim and asserts the same
  buffered limit price as the equivalent `maxSlippageBps: 200` order,
  so the publisher back-compat path cannot silently regress.

…ps-slippage-controls

…-controls' into feat/tat-1043-add-perps-slippage-controls