API-level payload size limits and query result caps [MED]

[HayimShaul]

Description
Enforce strict upper bounds on every write and read path exposed by the View API before data reaches the database layer. Write operations (AddTokenRequest, AddTransaction, AddMovement) should reject any call whose serialised payload exceeds a configurable maximum size. Query operations (QueryTransactions, QueryMovements, QueryTokenRequests) should require a bounded Pagination argument -- the Pagination type is already present in the codebase, so enforcing its use rather than treating it as optional is a low-friction change. This prevents a single oversized write or unbounded table scan from monopolising database resources.

Short Summary

• Enforce max serialized payload size on AddTokenRequest, AddTransaction, AddMovement
• Make Pagination parameter mandatory (not optional) in query operations

[Rama542]

Hi, I've been going through the open issues and this one caught my attention. The scope is clear and I think I have a good understanding of what needs to be done enforcing max payload sizes on the write operations and making Pagination` mandatory on the query side.

I'd like to take this on if it's still available. I'll start by tracing through AddTokenRequest, AddTransaction, and AddMovement to understand where the size check fits best, and look at how Pagination is currently used in the query methods to figure out the cleanest way to make it required.

Could you please assign this to me? Happy to share a draft approach before jumping into a PR if that would be helpful.

Thanks!