bug(get): ct get raw silently returns only the first page (10 of 645 rows) #100

Problem

ct get raw <path> returns ChurchTools' default first page and says nothing about it.

$ ct get raw "/groups" --env prod
10 rows          # the instance has 645

No warning, no meta echo, no hint that 635 rows were dropped. The typed ct get groups pages
correctly, so the two commands disagree by 635 rows on the same host, and the raw one is the one
people reach for when exploring an endpoint the typed commands don't cover
(/permissions/group_role, /dynamicgroups, /departments, …).

Passing a bigger limit doesn't rescue it — CT caps it:

$ ct get raw "/groups?limit=500" --env prod
✗ GET /groups?limit=500 failed (HTTP 400)  "limit" must be between 1 and 100

so the caller must know to hand-roll &limit=100&page=N and loop.

Why it matters

This is a correctness trap, not an inconvenience: the output is a valid-looking JSON array, so
a reader concludes the instance has 10 groups. I hit it while auditing coverage for
eqrm/ct-structure and only caught it because 10 was implausibly round.

ct already knows this failure mode. From src/resolve/resolver.ts (the #99 review):

getAll is what the catalogs below are actually read with: CT's list endpoints return only
their default first page (10 rows) for a plain get, which would make a campus, group type or
department past that page unresolvable by name on any real instance

The resolver was fixed. The user-facing command wasn't.

Suggested fix

Page ct get raw through getAll like the typed commands, or — if raw is meant to stay a
one-request escape hatch — print a stderr warning whenever the response looks paginated and
meta.pagination shows more pages than were returned. Either is fine; silence is not.

Acceptance

• ct get raw "/groups" returns all 645 rows, or warns loudly that it did not.
• The raw and typed forms never disagree on row count for the same path.
• A --page/--no-paginate escape hatch stays available for probing one page deliberately.