feat(api-server): wire batch-initiate endpoint to contract batch semantics

[okonkwofreeman001]

Closes #843
Closes #844

Summary

The POST /v1/swap/batch-initiate endpoint (aliased as /v1/swap/bulk/initiate) was unwired: after validating request shape and checking the idempotency store, it always returned 400 batch_initiate_swap not yet implemented.

This PR wires the endpoint to the batch semantics already implemented and validated in the AtomicSwap contract's batch tests (contracts/atomic_swap/src/batch_swap_features_tests.rs, batch_approval_tests.rs, batch_history_tests.rs) by mirroring batch_initiate_swap in contracts/atomic_swap/src/lib.rs.

What changed

api-server/src/handlers.rs

New validations matching the contract (previously missing):

• Batch size capped at MAX_BATCH_SIZE (50) → mirrors ContractError::BatchTooLarge
• Every price must be positive → mirrors require_positive_price / PriceTooSmall
• Existing checks retained: ip_ids/prices length mismatch, empty batch, duplicate ip_ids (Implement Swap Batch Deduplication #524), idempotency replay (Add Swap Batch Idempotency #523)

Execution pass mirroring the contract:

• Allocates sequential swap IDs via a process-local NEXT_SWAP_ID counter (stands in for the contract's NextId until handlers are wired to a live Soroban RPC client)
• Creates one SwapRecord per IP with status = Pending and expiry = now + 604800 (7 days, same as the contract)
• Persists records through the existing Add API Caching Layer #316 cache (cache::swap_key), so GET /swap/{swap_id} returns them
• Returns BatchInitiateSwapResponse { swap_ids } and caches the response under the Add Swap Batch Idempotency #523 idempotency key so replays return the same IDs instead of allocating new ones
• Updated the OpenAPI 400 description to reflect the full validation set

api-server/src/main.rs

Added handler tests:

• Success returns sequential swap_ids, and the created swaps read back via GET /swap/{id} as Pending with a future expiry
• Batch larger than 50 → 400
• Non-positive price → 400
• Idempotent replay with the same key returns the same swap IDs

Semantics mirrored from the contract

Contract (batch_initiate_swap)	Handler
BatchEmpty panic	400 "ip_ids must not be empty"
BatchSizeMismatch panic	400 "ip_ids and prices must have the same length"
BatchTooLarge (MAX_BATCH_SIZE = 50)	400 "batch size N exceeds maximum of 50"
SwapExists on duplicate ip_ids	400 "duplicate ip_id" (#524)
require_positive_price	400 "price must be positive for ip_id"
NextId sequential IDs	NEXT_SWAP_ID atomic counter
SwapRecord Pending, now + 604800 expiry	SwapRecord Pending, now + 604800 expiry, cached for GET /swap/{id}

Testing

Not run in this environment: it has no Rust toolchain, and api-server builds as a standalone workspace (it is excluded from the root workspace due to an async-graphql version conflict). Verify locally with:

cargo test --manifest-path api-server/Cargo.toml

The existing 400-path tests (test_batch_initiate_swap_mismatched_lengths_returns_400, test_batch_initiate_swap_empty_ids_returns_400) are unchanged and still pass.

[drips-wave]

@okonkwofreeman001 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits