entities: raise list/filter row cap 1000 → 5000 (Base44 parity); v0.2.0-next.7

[HomemadeToast57]

What

list/filter still page (50 rows by default), but the per-call ceiling was 1000 while Base44's is 5000 — so a Base44-modeled or migrated app silently truncated between 1000–5000 rows with no signal.

• Raise MAX_LIMIT 1000 → 5000 (Base44 parity).
• An over-cap limit now throws instead of silently clamping, so over-large reads fail loudly rather than returning a partial result the caller mistakes for the whole set.
• Page larger tables with limit + skip.

Why loud instead of silent

The silent 1000 clamp was the actual bug behind "my data looks cut off." Throwing on limit > 5000 keeps the safety ceiling (unbounded reads over the HTTP/PostgREST data plane are a real payload risk) without the silent-truncation footgun.

Notes

• updateMany/deleteMany still act on every matching row regardless of page size — unchanged, but now documented in the README so the read-caps/writes-don't asymmetry is explicit.
• Tests updated: default-50, allow-5000, throw-on-5001-before-network, filter defaults to 50.
• Version bumped to 0.2.0-next.7 → publishes to the next (canary) channel on release, invisible to latest.
• Paired with a bool-repo change that teaches the app-builder AI these limits in the entities system prompt.

🤖 Generated with Claude Code