Add a bulk withdraw endpoint to `routes/liquidity.ts` mirroring `anchorService.registerBulk`'s atomic-validation pattern

[Jagadeeshftw]

📌 Description

AnchorService.registerBulk validates an entire batch before persisting any of it, so a single bad entry never leaves a partial batch registered. LiquidityService has no equivalent for withdrawals: an operator needing to withdraw liquidity across many anchor/asset pairs at once (e.g. season-end reconciliation) must issue one POST /api/v1/liquidity/withdraw call per pair today, with no all-or-nothing guarantee across the batch.

🧩 Requirements and context

• Add LiquidityService.withdrawBulk(entries: unknown) that validates every { anchor, asset, amount } entry (existence of balance, sufficient amount) before applying any withdrawal, mirroring registerBulk's validate-then-apply-all structure.
• Add POST /api/v1/liquidity/withdraw/bulk in routes/liquidity.ts calling the new service method.
• A single invalid or insufficient-balance entry anywhere in the batch must cause the entire batch to be rejected with no partial withdrawals applied.

🛠️ Suggested execution

• Add withdrawBulk to src/services/liquidityService.ts, reusing requireString/normalizeAsset/requirePositiveNumber and validating sufficiency for every entry before calling this.repo.upsert/remove for any of them.
• Add the route in 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 batch with one invalid entry asserting no withdrawals from valid entries in the same batch were applied.

✅ Acceptance criteria

• POST /api/v1/liquidity/withdraw/bulk withdraws every valid entry in a batch atomically.
• A single invalid entry rejects the whole batch with no partial effect, verified by a test asserting balances are unchanged after a rejected batch.
• New endpoint documented in openapi.ts.

🔒 Security notes

Atomicity of the batch prevents a partially-applied bulk operation from leaving liquidity accounting in an inconsistent intermediate state.

📋 Guidelines

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