Add a regression test documenting that the static `GET /api/v1/liquidity/entries` route takes precedence over `GET /:asset`

[Jagadeeshftw]

📌 Description

routes/liquidity.ts mounts GET /entries (static) before GET /:asset (parameterized), so Express's route-matching order means a request to /api/v1/liquidity/entries always hits the entries handler and can never be interpreted as getPool("entries"). This is correct today only because of registration order — a routine-looking refactor that reorders the two router.get(...) calls would silently break GET /api/v1/liquidity/entries by making it fall through to :asset matching instead.

🧩 Requirements and context

• Add a test asserting GET /api/v1/liquidity/entries returns the entries list shape ({ entries: [...] }), not a 404-or-pool-shaped response for a nonexistent "ENTRIES" asset.
• Add a code comment directly above the two route registrations in routes/liquidity.ts calling out that their order is load-bearing.
• Add a short note to the README or openapi.ts describing this constraint if either documents route ordering elsewhere (otherwise, the code comment plus test suffice).

🛠️ Suggested execution

• Add the regression test to src/routes/liquidity.test.ts.
• Add the explanatory comment to src/routes/liquidity.ts directly above the router.get("/entries", ...) and router.get("/:asset", ...) calls.

✅ Acceptance criteria

• New test passes and would fail if the two route registrations were swapped.
• Comment in routes/liquidity.ts clearly documents the ordering dependency.

🔒 Security notes

N/A — test/documentation only; prevents an accidental route-shadowing regression during future refactors.

📋 Guidelines

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