Add a `transferLiquidity(from, to, asset, amount)` operation to `LiquidityService` mirroring an anchor-to-anchor on-chain transfer

[Jagadeeshftw]

📌 Description

Today, moving liquidity between two anchors requires a withdraw from one anchor followed by a separate add for the other, which is neither atomic nor auditable as a single logical operation, and briefly reduces total pool liquidity between the two calls. Add a dedicated transfer operation that performs both halves atomically in memory.

🧩 Requirements and context

• Add LiquidityService.transferLiquidity(input: { from: unknown; to: unknown; asset: unknown; amount: unknown }) that validates the source anchor has sufficient balance, then atomically decrements the source and increments the destination for the same asset.
• If the source has insufficient balance, no state should change (matching withdrawLiquidity's existing INSUFFICIENT_LIQUIDITY error).
• Add POST /api/v1/liquidity/transfer in routes/liquidity.ts.

🛠️ Suggested execution

• Add transferLiquidity to src/services/liquidityService.ts, reusing existing validation helpers and the same insufficient-balance error code as withdrawLiquidity.
• Add the route to src/routes/liquidity.ts.
• Update src/openapi.ts with the new path.
• Add tests in src/services/liquidityService.test.ts and src/routes/liquidity.test.ts, including a failed transfer leaving both anchors' balances unchanged.

✅ Acceptance criteria

• POST /api/v1/liquidity/transfer moves liquidity between two anchors for the same asset in a single atomic operation.
• An insufficient-balance transfer leaves both the source and destination balances completely unchanged.
• New tests pass for both the success and failure paths.

🔒 Security notes

Atomicity prevents a partially-applied transfer (debited from source but not credited to destination, or vice versa) from corrupting total pool accounting.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours