Add "New Position" view for providing liquidity

[0x-r4bbit]

Create a "New Position" view in the DEX app that allows users to select two tokens, choose a fee tier, and deposit token amounts to either
create a new pool or add liquidity to an existing one. Inspired by https://app.uniswap.org/positions/create/v2.

Background

The AMM program supports two instructions for providing liquidity:

• NewDefinition — initialises a new pool (or re-initialises an inactive one) with an initial deposit of Token A and Token B, a fee tier,
  and sets up the vault accounts and liquidity token definition via PDAs.
• AddLiquidity — deposits into an already-active pool up to specified maximum amounts of Token A and Token B, receiving LP tokens in
  return, subject to a minimum liquidity output guard.

The view must detect which instruction to use based on whether the selected pool already exists and is active.

UX Flow

1. Select token pair — user picks Token A and Token B from their available token holdings
2. Select fee tier — user picks from the four supported tiers:

• 0.01% (1 bps)
• 0.05% (5 bps)
• 0.30% (30 bps)
• 1.00% (100 bps)

3. Pool status indicator — after the pair + fee tier are selected, the view queries the chain for the pool PDA and shows one of:

• Pool exists — current reserves and exchange rate are displayed; deposit amounts are constrained to preserve the ratio
• Pool does not exist — user sets the initial price freely by entering both amounts independently

4. Enter deposit amounts — two input fields (one per token), each showing the user's available balance; when the pool exists, adjusting one
   field auto-calculates the other to maintain the reserve ratio
5. Preview & confirm — summary shows estimated LP tokens to be received (or minted for a new pool), fee tier, and the accounts that will be
   created/updated
6. Submit — dispatches NewDefinition or AddLiquidity instruction accordingly

Technical Notes

• Pool existence is determined by computing the PDA (compute_pool_pda) from the AMM program ID and the two token definition IDs, then
  checking whether the account exists and is active (see active flag in PoolDefinition is redundant after MINIMUM_LIQUIDITY lock #25)
• For NewDefinition, all seven required accounts (pool, vault A, vault B, liquidity token definition, user holding A, user holding B, user LP holding) must be passed; vault and liquidity token PDAs can be derived via compute_vault_pda / compute_liquidity_token_pda
• For AddLiquidity, the same seven accounts are required (all must already be initialised)
• LP token amounts to preview can be estimated client-side using the constant-product formula against the current reserve_a, reserve_b, and liquidity_pool_supply from PoolDefinition
• Input validation must reject equal token definitions (pool PDA computation panics on equal IDs)

Acceptance Criteria

• User can select a token pair and fee tier
• View correctly detects whether the pool exists and adjusts the UI accordingly
• Deposit amounts are validated against the user's available balances
• When the pool exists, amounts are kept in ratio with the current reserves
• Preview shows estimated LP tokens received
• Submitting dispatches the correct instruction (NewDefinition vs AddLiquidity)
• Error states (insufficient balance, pool inactive, equal token IDs) are surfaced clearly

References

• Uniswap v2 position creation UI: https://app.uniswap.org/positions/create/v2

[0x-r4bbit]

This has landed via #210