Feathers service pagination without explicit `paginate.max` leaves `$limit` unbounded per adapter

Feathers services accept a paginate object with default and max properties, but the framework does not impose a built-in upper bound on the $limit query parameter when max is omitted. Pagination enforcement is delegated to the underlying database adapter, so the effective ceiling for an unbounded $limit can differ between Knex, Sequelize, Mongoose, and the memory adapter, and may shift across adapter or core version upgrades. This leaves an unresolved boundary for applications that expose public or newly scaffolded services without an explicit max: the maximum result-set size is determined only by the specific adapter in use, with no consistent framework-level default.

Given that max is treated as an opt-in safeguard rather than a default, where should responsibility for a global $limit ceiling reside when individual services omit it? Should the boundary be enforced uniformly at the Feathers service layer, or is adapter-specific clamping sufficient across versions? How can an application confirm that a large $limit is constrained for every adapter and release combination it deploys without relying on undocumented behavior?