Surface more project prebuilds in the dashboard

Problem to solve

When we introduced prebuilds in the dashboard last year, we carefully started by surfacing only the most recent (30) prebuilds.

While older prebuilds logs are still accessible via URL, users cannot access or discover older prebuilds and keep track of prebuilds status or logs. For example, the GitLab team was trying to find older prebuilds to figure out why some prebuilds were failling with a SYSTEM ERROR and ER_LOCK_WAIT_TIMEOUT messages, see https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/1531 and relevant discussion.

Proposal

Now that we have 🅰️ completed the next iteration on improving prebuilds reliability[1] and 🅱️ a better pagination component[2] in place to support long data lists as part of our efforts to switch to UBP (Usage-Based Pricing), we can consider surfacing more, if not all, prebuilds for a project.

The proposal of this issue is to surface more, if not all, prebuilds for a project and use the new pagination component to do so reliably and with performance in mind. 💭

Start by locating the dashboard code that lists project prebuilds and inspect how the newer pagination component is used for long data lists. Trace the current limit of 30 and the available prebuild status or log links. Done means older, potentially all, project prebuilds are discoverable through reliable, performant pagination.