chore: Keep legacy trades reads bounded and predictable

[milaforge]

Background

GET /api/v1/trades is deprecated, but it can still return all matching trades for an owner or order. The v2 endpoint already has pagination and a clear max limit, so the old endpoint has a less predictable resource profile.

Details

My suggested direction is to keep the endpoint backward-compatible, but make the backend work bounded: apply a conservative default/max limit internally.

Acceptance criteria

• Decide the intended behavior for bounded v1 trades responses.
• Add tests for the v1 bound and existing filter validation.
• Update OpenAPI/docs so integrators know v2 is the paginated path.
• Add or reuse metrics/logging so capped legacy responses are observable.

[0xDevNinja]

@milaforge picking this up.

v1 currently passes i64::MAX as the limit so it's unbounded, while v2 caps at 1000. Plan: cap v1 internally, log/metric when a response gets capped, update the OpenAPI note, add tests.

One question before I start. What cap do you want, same 1000 as v2, or higher so we don't silently cut off existing v1 callers?

[milaforge]

I'm not sure if this is a priority for the team at the moment, so I suggest you put your efforts somewhere its actually needed.