builds: the list is capped at 50 with the window unstated, so filtering can raise the run count #244

From an outside review of the web UI. The finding is the complaint; the suggestion below is one way out, not a decision.

Observed: the unfiltered builds page showed 23 runs; filtering to failures showed 42, all older. Filtering appeared to increase the total.

The mechanism is the cap. build list takes the newest 50 builds matching the filter (internal/control/build.go:127) and has no --limit/--cursor, unlike issue list, mr list, repo list and feed. The page dispatches that command (internal/httpd/builds.go:214-224) and groups what comes back. Unfiltered, 50 builds are 50 recent builds, which fold into few runs. Filtered to failures, the same 50 reach much further back and fold into more runs, because failures are sparse and rarely share a queueing.

Nothing on the page says any of this: the count line reads "N builds in M runs" with no window and no pagination, so a larger number after filtering looks like a bug.

One option: say what the window is (newest 50 matching builds) next to the count. Another: give build list the keyset cursor the other list commands have and page the web view, which removes the window rather than explaining it.