Add a maximum batch size cap to register_anchors/provide_liquidity_multi/withdraw_liquidity_multi

[Jagadeeshftw]

📌 Description

register_anchors(anchors: Vec<Address>), provide_liquidity_multi(provider, requests: Vec<(Symbol, i128)>), and withdraw_liquidity_multi(provider, requests: Vec<(Symbol, i128)>) in src/lib.rs all accept an unbounded Vec with no size check before iterating it (once for validation, once for application). A caller submitting an extremely large batch risks exceeding the transaction's instruction budget partway through, and there is currently no contract-level guard or dedicated error distinguishing "batch too large" from a generic execution failure.

🧩 Requirements and context

• Introduce a MAX_BATCH_SIZE constant in src/lib.rs (alongside MAX_FEE_BPS) and a new Error::BatchTooLarge variant in src/error.rs.
• Enforce the cap as an early check in register_anchors, provide_liquidity_multi, and withdraw_liquidity_multi, before any validation or mutation begins.
• Add regression tests asserting a batch at the cap succeeds and one over the cap fails cleanly with Error::BatchTooLarge and zero side effects.

🛠️ Suggested execution

• Add the constant and error variant, then add the guard to all three entrypoints in src/lib.rs.
• Add src/test.rs coverage for at-cap, over-cap, and zero-length batches (the latter already covered by Error::InvalidAmount for the _multi functions — confirm the new check doesn't shadow that).
• Update the README to note the batch size limit next to each affected entrypoint.

✅ Acceptance criteria

• All three batch entrypoints reject a batch exceeding MAX_BATCH_SIZE with Error::BatchTooLarge before any state is touched.
• A batch at exactly the cap succeeds.
• Existing empty-batch (Error::InvalidAmount) and duplicate-entry (Error::AnchorAlreadyRegistered/Error::DuplicateAssetInBatch) checks are unaffected.

🔒 Security notes

An unbounded batch that runs out of instructions mid-application is exactly the kind of partial-failure risk the atomic validate-then-apply pattern in these functions is designed to avoid; a hard cap removes the failure mode at the input-validation layer instead of relying on the runtime to fail safely.

📋 Guidelines

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