Add pagination to `GET /api/v1/liquidity/entries` in `routes/liquidity.ts`

[Jagadeeshftw]

📌 Description

Like GET /api/v1/anchors, GET /api/v1/liquidity/entries returns every raw entry with no pagination. Combined with the planned ?asset= filter, a deployment with many anchors and assets could return an unbounded response for this endpoint today.

🧩 Requirements and context

• Wire utils/pagination.ts's paginate into GET /api/v1/liquidity/entries, applied after any asset filtering.
• Response shape should include a pagination object alongside entries, matching the convention used elsewhere (routes/settlements.ts).

🛠️ Suggested execution

• Modify src/routes/liquidity.ts's GET /entries handler to apply paginate from src/utils/pagination.ts to service.listEntries(...)'s result.
• Update src/openapi.ts's /api/v1/liquidity/entries entry to add page/pageSize parameters.
• Add tests in src/routes/liquidity.test.ts for paginated responses.

✅ Acceptance criteria

• GET /api/v1/liquidity/entries?page=1&pageSize=5 returns a correctly-sliced page with a pagination object.
• Omitting pagination params returns a sensible default page rather than the full unbounded list.
• Existing liquidity.test.ts tests for unfiltered/filtered entries continue to pass with the new envelope shape.

🔒 Security notes

N/A — read-path pagination; reduces unbounded-response risk as entry count grows, no new data exposure.

📋 Guidelines

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