SQLEntity.get() no longer reads `req.body.rows` for pagination

• Breaking: SQLEntity.get() no longer reads req.body.rows for pagination. req.body.rows means "array of entities to act on" everywhere else in this class (add, update, upsert, delete, archive, sync) - reusing the same key for get()'s page size was error-prone (e.g. a stray rows array left over from a different request shape could get misread as a numeric LIMIT, producing invalid SQL). Page size is now exclusively req.body.limit (a number). Callers relying on { rows: <number> } for pagination must switch to { limit: <number> }.
• Renamed the internal/public rows parameter to limit in Select.query(), the exported filter() function, and SQLEntity.query.select() for clarity, matching the req.body.limit field name above.
• Fix addOneSubstack/updateOneSubstack/upsertOneSubstack: normalizeOne/validateOne (from @dwtechs/antity) operate directly on req.body as the single entity object with no rows wrapper, but add()/update()/upsert() unconditionally read req.body.rows, which doesn't exist in that shape - calling any *OneSubstack crashed (rows.map/chunk on undefined). Added a resolveRows() helper so add()/update()/upsert() now accept either req.body.rows (array, Array substacks) or req.body itself (single object, One substacks), and return a clean 400 instead of crashing when neither shape is present or req.body.rows is an invalid (non-array) value.