fix(issues): Cap page size on full=true event and hash listings

[oioki]

full=true serializes a complete event body per row with EventSerializer, so the cost of a page scales with the frames inside the events, not the row count. per_page counts rows and defaults to 100 — a poor fit for native events, whose bodies can be very large, where a single page can reach hundreds of megabytes and take a long time to build.

#122718 clamped this on GroupEventsEndpoint. The same pattern lives on two endpoints that were missed:

• ProjectEventsEndpoint — full opt-in, project-scoped (so the page can pull heavy events from anywhere in the project).
• GroupHashesEndpoint — full defaults to true, and each row already serializes a full latestEvent.

This moves the shared cap out of group_events and into the event serializer module — next to EventSerializer, the thing that makes full expensive and which all three endpoints already import from — then applies the same get_per_page override on all three.

Cursors are unaffected (GenericOffsetPaginator encodes only the offset), so callers still page through the whole set; the page is just smaller. Because full defaults to true on GroupHashesEndpoint, this lowers its default page size for every caller, not only opt-in ones — that is the one behavior change worth a careful look.

The cap is denominated in rows, so a single very large event still costs what it costs; bounding an individual event body is a separate change.

Refs VULN-2870, VULN-2871

[linear-code]

VULN-2870

VULN-2871