OB-054: Build a meaningful spread and reference-price row #706

Priority: P1 · Size: S · Area: order-book-ui · Depends on: OB-019, OB-046, OB-051

Motion skills: Agents and developers must use .agents/skills/animate/SKILL.md and .agents/skills/review-animations/SKILL.md, following the required workflow below.

Scope: Show spread in quote units and percentage, with last trade or mark
price explicitly identified. Use the agreed policy when either side is absent
or the book revision is invalid.

Acceptance criteria:

• Fixtures verify the spread denominator, precision, and labels; unavailable calculations render an explanation instead of NaN or zero.
• Price direction emphasis is restrained, values remain immediately readable, and oracle/mark data is never labeled as a fill.

Season context

Build a standard order book trading experience for SO4 on Stellar: a compact watchlist and market header, a large chart, an adjacent order book/recent-trades panel, a right-hand order ticket, and account tables below. Preserve SO4's brand and shared design tokens. Keep verified perpetuals capabilities; do not add Pro mode, EVM wallet connection, new margin modes, TWAP, or spot/perps transfers solely to imitate the reference layout.

An order book layout does not establish an executable order book. Matching, resting depth, partial fills, signing, and settlement need verified sources; account orders, oracle prices, pool liquidity, and illustrative data are not substitutes for executable depth. Preserve geometry during loading and live updates. Motion should clarify state changes, with reduced-motion, focus, touch, and interruption behavior included.

Extend the existing custom @workspace/ui/components/toast implementation; do not install Sonner or a second toaster. Use TanStack Query for scoped caching, targeted refresh, and explicit indexer catch-up after confirmed transactions.

Common completion rules

• Follow AGENTS.md, including reproduction and regression
  coverage for bug fixes, the full ordered commit gate, and integration checks for
  web/indexer changes. Do not weaken checks. Dependency/build changes require the
  clean-room verification specified there.
• Use existing components and named design tokens from
  packages/ui. Token changes include the corresponding
  DESIGN.md documentation. No parallel theme or toast system.
• Use explicit MSW handlers for network tests. Include relevant success, empty,
  stale, and failure behavior; keep timers and streams deterministic. Visual work
  includes desktop/mobile and reduced-motion review, with relevant theme coverage.
• Include a user-visible changelog entry when required by the repository's
  entry format. Documentation changes
  follow apps/docs/CONTRIBUTING.md.
• Distinguish wallet approval, submission, ledger confirmation, order acceptance,
  execution/partial fill, and indexer catch-up. A transaction confirmation must
  never falsely imply that a resting order has filled.
• Use targeted invalidation after confirmed changes, and explicitly handle
  inactive queries when their views next open. Invalidating an active query marks
  it stale and triggers background refetch; it does not prove an indexer has
  caught up. See TanStack Query invalidation.
• Cache freshness and retention are separate choices. Define them by data class,
  rather than treating a long staleTime as a real-time strategy. See
  TanStack Query defaults.
• Measure speed on the baseline device/network profile in OB-010. Initial field
  targets are p75 LCP ≤ 2.5 s, INP ≤ 200 ms, and CLS ≤ 0.1, reported separately
  for landing and trading and for mobile/desktop. Lab results are diagnostics,
  not a substitute for field percentiles. See Web Vitals.

Required animation skills for agents and developers

The named skill files exist in the maintainer’s local checkout but are not yet available on the published main branch. Obtain them from the maintainer if your checkout lacks them before implementing motion. The required workflow is reproduced below so this issue is self-contained.

This issue requires both coding agents and human developers to follow the repository's Emil Kowalski-based guidance:

1. Read .agents/skills/animate/SKILL.md before designing
   or implementing motion. Decide whether the interaction should animate, state its
   purpose, reuse existing tokens, and choose the smallest suitable implementation.
   Use the relevant .agents/skills/animate/RECIPES.md, adapting
   examples to the existing components and approved motion budget.
2. Apply .agents/skills/review-animations/SKILL.md
   before review. Consult its .agents/skills/review-animations/STANDARDS.md
   for precise timing/easing guidance. Agents explicitly load the skills; developers
   use the same files as implementation and review checklists.
3. Attach the motion purpose, token/property choices, normal/reduced-motion clips,
   and rapid-interruption evidence to the PR. Include the review's findings table
   and verdict; address blocking findings before marking the issue complete.

These requirements are part of this issue's acceptance criteria. A generic
fade on every element is not sufficient. Prefer restrained feedback in trading,
stable readable values, trigger-aware overlays, and richer but inexpensive landing
motion. Skills guide the craft; the user's requirement to reuse packages/ui
components and its existing toast remains authoritative. Do not replace that toast
with Sonner or another library to follow a recipe.

Priority key: P0 = prerequisite/correctness; P1 = core experience; P2 = later polish. Size: S/M/L describes relative scope, not a delivery-time promise.