Wayfinder: New Position view for AMM liquidity

[3esmit]

Destination

Issue 30 is implemented from current main: the AMM app has a production New Position flow that lets a wallet user select two token holdings and fee tier, detects whether the pool exists and is active, previews LP output and touched accounts, and submits NewDefinition or AddLiquidity with current-main account requirements.

Notes

Source issue: Add "New Position" view for providing liquidity

Use current main as baseline. Do not depend on prior prototype PR implementations. Consult the QML, AMM program, and Rust guides when touching QML/C++/Rust. Keep UI aligned with existing apps/amm patterns and Logos design-system imports. Treat current program code and guest account order as authoritative over issue prose.

Current-main facts to preserve:

• The app currently has Trade and Liquidity tabs only; Liquidity uses DummyPoolState.
• The AMM backend currently exposes wallet/account lifecycle but no pool discovery, token-holding model, or AMM submit surface.
• Current AMM instructions require config/current-tick/clock accounts; NewDefinition also needs LP-lock holding. Do not implement against the seven-account simplification in Issue 30.

Decisions so far

Fog

• Whether AMM-specific submit/query helpers belong in the AMM UI backend, the logos_execution_zone module, or a shared LEZ client wrapper depends on the backend surface ticket.
• Exact token metadata naming/symbol display may require a separate token-definition discovery ticket after holdings source is known.
• Existing Liquidity/AddLiquidity mock components may be reused, split, or replaced once the New Position state model is decided.
• Testnet/mainnet program IDs and AMM config source need a concrete deployment/config decision before real submissions can ship.
• Automated coverage shape is unclear until the backend boundary and QML state model are fixed.

[3esmit]

Completed in PR #210 by commit 7f88fd0. The New Position flow now uses live wallet and chain state, canonical AMM ordering with user-selected display order, exact raw u128 quote and instruction planning, testnet/devnet-scoped program configuration, active and missing pool handling, funding simulation, fee-tier constraints, account previews, and optimistic external-wallet submission with transaction-hash feedback. Subissues #218, #219, #222, #223, and #224 are complete. All seven GitHub Actions checks pass. PR #210 remains open for review.