fix(list): read a capped total as a floor and trust has_next_page past it

[ysyneu]

Problem

The incident, alert and alert-event list endpoints stop counting at 1000. Past that they keep returning rows but report total: 1000, so:

• page 1 printed showing 100 of 1000 total results, which reads as the exact size of the set;
• pages past the cap (e.g. --page 11 --limit 100) printed no hint at all, because the page offset had already passed the reported total.

Change

• listPage.TotalCapped marks endpoints whose count is capped; PrintCappedList sets it together with has_next_page for incident list, alert list, alert-event list and alert events.
• A capped total that reached 1000 reads at least 1000 (footer: total at least 1000; note: showing 100 of at least 1000 total results (page 1): raise --limit or use --page 2).
• For such a total, whether rows remain is decided by has_next_page alone, not by the page offset.
• Uncapped lists are unchanged, including a real total of exactly 1000.

Testing

• Table cases in internal/cli/list_completeness_test.go for capped page 1, past the cap with has_next_page true/false, has_next_page=false overriding the offset, a capped endpoint below the cap, and an uncapped total of 1000.
• go test ./... and make lint pass.
• Against the live API: incident list --limit 100 pages 1, 11 and 100 print showing N of at least 1000 total results; change list still prints of 219.