fix(org): bound limit/offset on ORGANIZATION_MEMBER_LIST

[pedrofrxncx]

Source: bug found while hardening apps/api/src/tools/organization/member-list.ts (this tick's focus area).

Why: ORGANIZATION_MEMBER_LIST's limit/offset input fields were a plain z.number().optional() with no bounds — every other paginated tool in the repo constrains these (e.g. CollectionListInputSchema in packages/bindings/src/well-known/collections.ts caps limit at 1-1000 and requires offset >= 0, both as integers). A caller could pass an unbounded (limit: 1_000_000), negative, or fractional value straight through to Better Auth's listMembers, with no validation catching it at the tool boundary.

Failure scenario: ORGANIZATION_MEMBER_LIST({ limit: 1_000_000 }) or { limit: -1 } or { limit: 1.5 } all passed Zod validation before this fix and were forwarded verbatim to ctx.boundAuth.organization.listMembers.

Fix: limit: z.number().int().min(1).max(1000).optional(), offset: z.number().int().min(0).optional() — matching the existing repo-wide pagination convention.

Regression test: added a case in member-list.test.ts asserting the schema rejects an over-cap, negative, and fractional limit/offset, and still accepts a valid bounded value.

To verify: cd apps/api && bun test src/tools/organization/member-list.test.ts

Checked locally: bun run fmt, bunx tsc --noEmit (apps/api), the targeted test file above, and bunx oxlint on both changed files — all clean. Full CI validates the rest.

---

Summary by cubic

Bounds pagination inputs for ORGANIZATION_MEMBER_LIST to integers: limit 1–1000 and offset >= 0, matching repo pagination conventions. Previously any number was accepted; now invalid values fail validation, preventing unbounded, negative, or fractional inputs from reaching the auth backend.

• Client requirements: pass an integer limit within 1–1000 and an integer offset >= 0; out-of-range or non-integer values will throw at the tool boundary.

^{Written for commit 98d8e7a. Summary will update on new commits.}