fix(ci): align ci delete and ci list default pagination

Summary

Closes #1324 (closed).

glab ci list --status=success and glab ci delete --status=success returned different counts because ci list hardcoded PerPage: 30 while ci delete used the API default of 20. Worse, ci delete silently truncated to 20 with no indication that more matching pipelines existed — users could believe "delete all failed pipelines" had actually deleted all of them.

This MR:

• Drops the hardcoded PerPage: 30 in ci list so it falls through to the GitLab API default (20). Behavior is unchanged when the user passes --per-page explicitly.

• Updates ci delete to surface a stderr message when results were truncated, telling the user how many matched in total and pointing at --paginate / --per-page:

  Deleted 20 of 67 matching pipelines. Pass --paginate to act on all matches, or --per-page to fetch more per request.

  (Uses Matched instead of Deleted under --dry-run.)

This matches phikai's original preference that commands not override API defaults, and addresses jay's concern that ci delete would mislead users about how many pipelines a filter actually affects.

Test plan

• go test ./internal/commands/ci/delete/... ./internal/commands/ci/list/... passes
• Two new tests in delete_test.go exercise the truncation warning for the real-delete and dry-run paths
• golangci-lint run ./internal/commands/ci/delete/ ./internal/commands/ci/list/ clean
• make gen-docs re-run; docs/source/ci/list.md updated
• Manual smoke test on a real project where ci list --status=success shows more than the per-page default