fix(webapp): say when the board is showing fewer cards than match

[NathaelB]

Refs #461, #466. Found during the chantier's completeness pass, after all seven workstreams had merged.

The bug

BOARD_TASKS_PER_PAGE was 200. PaginationParams::per_page (libs/pagination/src/lib.rs:24) clamps every listing to MAX_PER_PAGE = 100, and GET /tasks goes through it (list.rs:294).

Asking for more does not fail and does not warn. It comes back with 100. So a board in an organization past a hundred tasks was missing cards with no indication, while its own doc comment claimed the opposite:

The board is not a pager: it shows every root task at once

Every column count was wrong, and the counts are what a board is read for.

The fix

The constant is now honest. 100, with a comment saying that it is the ceiling rather than a preference, that raising it buys nothing until the clamp moves, and that the board says when a listing was cut instead.

The board reads pagination.total — how many tasks match the current filters, which is not how many came back — and says so above the columns when the two differ:

4 tâches affichées sur 247. Affinez les filtres pour voir les autres.

Rendered in an <output> beside the columns rather than in place of them: the cards that did come back are still the ones being worked on. It sits above the columns and inside the same card as the filter bar, so it survives a filtered board coming back empty.

Three tests

• says how many cards it is showing when the match set is larger — the notice, with its numbers.
• says nothing when every matching card came back — the ordinary board stays quiet.
• keeps saying it while a card is being moved — the one worth explaining. The optimistic move rewrites data in the cache entry; if it dropped pagination on the way, the notice would blink off on every drag and return at the refetch. A board that forgets it is truncated while you work in it is worse than one that never said so. The test moves a card with the keyboard and asserts the notice holds.

That third test replaced a worse one. The first version asserted "says nothing when the match set is smaller than the page", which pins an incoherent state — the server cannot return more rows than it counts. The real risk was never a total below the page size; it was pagination being lost by the write path.

Two existing assertions moved from per_page: 200 to 100, argument and expectation together: they were pinning the value this change corrects.

What this does not do

It does not raise the cap, and it does not paginate per column. Both are real options — the first is a one-line change to MAX_PER_PAGE with consequences for every other listing, the second is a redesign of the board's read. This change makes the existing limit visible, which is the part that was wrong rather than merely small.

Verification

pnpm check   # 548 files, no fixes applied
pnpm test    # 1867 passed, 180 files
pnpm build   # ✓ built

[codspeed]

Congrats! CodSpeed is installed 🎉

🆕 11 new benchmarks were detected.

You will start to see performance impacts in the reports once the benchmarks are run from your default branch.

Detected benchmarks

• client_ip_x_forwarded_for: 4.6 µs
• client_ip_x_real_ip: 3.3 µs
• inject_headers_allowed: 4.5 µs
• inject_headers_blocked: 4.5 µs
• client_ip_fallback_only: 4.2 µs
• ip_v4_key: 4.2 µs
• decode_realistic_token: 37.1 µs
• extract_claims: 38.1 µs
• client_ip_forwarded_header: 4.2 µs
• ip_v6_key: 4.2 µs
• organization_key: 4.2 µs

---