fix(admin): match the list windows the auth API enforces

[Bccorb]

Follows fells-code/seamless-auth-api#299, which gave GET /admin/users the same validated window the other admin collections already had.

The flag bounds

The API takes a limit of 1 to 100 and an offset of 0 or more. The CLI checked both flags with one function against one range, floor zero. That is right for --offset, where zero is the first page, and wrong for --limit, so users list --limit 0 and users list --limit 500 were sent and came back as a 400 naming neither the flag nor the bound.

Each flag is checked against its own range now, and the message says which one was wrong and what it accepts:

--limit must be a whole number between 1 and 100.
--offset must be a whole number of 0 or more.

--limit 0 is now an error rather than a request for nothing. The old comment called zero a legitimate answer, but the floor was really there for --offset, which the same function validated. The alternative was to keep it and skip the request, and I did not, because printing "No users." when the CLI never asked says there are none. That is worse than saying the flag is out of range.

org list was silently truncating

Not in the original ask, but caused by fells-code/seamless-auth-api#288, so I would rather not leave it: org list sent no window at all. Once the API started defaulting to 50 it printed the first 50 organizations and then "140 organizations." — a count of every organization, including the 90 it had not shown, with no flag to reach them.

It now takes --limit, --offset and --search, and reports position the way users list already did:

Showing 51-51 of 140 organizations.

--search matches name and slug server-side, using the parameter the API gained in #288.

Say the word if you would rather this were its own PR and I will split it out.

Refactor

The window parsing and the position line moved to adminShared, since two commands need both and the next list command will need them too. users list behaviour is unchanged apart from the bounds.

Not affected

sessions list calls /sessions, the caller's own sessions, which takes no query parameters. It is the only other list command, so users and org are the whole surface.

Verification

• npm run build clean (tsc type-checks)
• npm test: 1001 passing, 4 skipped (up from 998)
• npm run coverage passes: 99.39 lines overall, and adminShared.ts, org.ts and users.ts all at 100
• Help text for both commands updated with the ranges