feat!: bound pagination limit and page through list endpoints - #27807

Summary

Stacked on #28028. Marked experimental: the open items below are not done.

ParsePagination left an omitted limit at 0, which every downstream query
treats as "no limit", so any client could ask a list endpoint for the entire
table in one request. It now resolves an omitted limit to
codersdk.MaxPaginationLimit (100) and rejects a limit outside 1..100 with a
validation error rather than clamping it.

• MaxPaginationLimit lives in codersdk, next to the Pagination type that
  carries it, so clients can size their own page requests.
• CLI commands that relied on an omitted limit returning every row now page to
  exhaustion: coder list, coder users list, template versions, template
  pull, and SSH completion.
• Frontend callers that sent limit: 0 either request a single row when they
  only read the count, or page to exhaustion (org members).
• Dead per-endpoint limit checks removed from enterprise/coderd/aibridge.go.

Breaking change

?limit=0 and ?limit=<n> for n > 100 now return 400 on every endpoint that
uses ParsePagination. Clients that relied on limit=0 meaning "all rows" must
page. The Go SDK never put limit=0 on the wire, so Go integrators see
truncation rather than an error.

Testing

• go test ./coderd/ -run TestPagination
• go test ./support/ -run TestRun
• go test ./codersdk/ -run TestAllWorkspaces
• pnpm vitest run src/api/api.test.ts

Outstanding review items

Blocking, each corroborated by more than one reviewer:

• enterprise/cli/groupedit.go:64 calls client.Users unpaginated, so
  --add-users/--rm-users silently resolves against the first 100 users.
• /templates/{template}/acl/available truncates at 100. GetGroups has no
  OFFSET and no ORDER BY, and codersdk.ACLAvailable has no count, so
  the truncation is neither pageable nor detectable.
• The aibridge maximum dropped from 1000 to 100 and the error shape changed
  from Detail to Validations. codersdk/aibridge.go still documents
  1000. Decide whether to keep 100 and declare it, or give those endpoints
  their own cap.

The stated invariant does not hold yet:

• ?limit=0 is still unbounded on coderd/provisionerjobs.go and
  coderd/provisionerdaemons.go.
• coderd/exp_chats.go (chatCostUsers) accepts up to MaxInt32;
  enterprise/coderd/agentfirewall.go has a default but no maximum.
• offset is uncapped and the sort runs before OFFSET, so this bounds
  response size, not database work. It should not be described as a DoS
  mitigation.

Contract and documentation:

• No docs/reference/api/ page states the bound, and the documented
  ?limit=0 curl examples in audit.md and enterprise.md now return 400.
• enterprise/coderd/templates.go, coderd/exp_chats.go (listChats), and
  the aibridge models/clients endpoints reject out-of-range limits without
  documenting a limit or offset parameter.
• MaxPaginationLimit's comment claims it is the server-wide maximum;
  exp_chats enforces 1-200 and 0-2000 elsewhere. Scope the wording to
  endpoints that use ParsePagination.

Tests and lower priority:

• coderd/pagination_test.go asserts only apiError.Message, which is the
  same constant for every failure. Assert Validations[0].Field, the detail
  text, and that exactly one validation error is returned.
• No endpoint-level test that a list route with more than 100 rows returns
  at most 100.
• ?limit= (present but empty) resolves to 100 instead of erroring, and
  ?limit=&limit=50 silently discards the 50.
• cli/userlist.go and cli/templateversions.go page by offset where those
  endpoints support AfterID.
• coder templates pull walks every version page to produce one warning.

This pull request was created by Coder Agents on behalf of @jscottmiller.