[skygunner]

Problem

useProjects raises the requested limit by PROJECT_PAGE_SIZE on every Load more click but clamps at 2000 — the same cap the Server-side projects query enforces. ProjectsView rendered the Load more button purely from truncated, so once the requested limit reached 2000 and the response was still truncated, the button stayed enabled while its click could not change anything: the query was re-clamped to the same 2000 rows, truncated stayed true, and the request count did not move.

Reproduced at the hook level with a 2001-row fixture: at the cap the button was offered, loadMore() issued no request, and the user had no explanation why the remaining workspace was not reachable.

Change

• useProjects now exposes canLoadMore (requested limit below the 2000 inventory cap) alongside the existing canShowLess.
• ProjectsView renders the Load more button only while widening is possible. At the cap it shows a short note instead: the inventory is capped at 2000 workspaces, and narrowing the filters (search / runner) shows more.
• Pagination below the cap, Show less, and the filter-driven page reset are unchanged; the 2000 cap itself is unchanged.

zh-CN wording ships in the existing runtime i18n map; other locales fall back to English like the neighboring bounded-inventory note.

Validation

• New hook test in frontend/test-v2/progressive-loading.test.tsx: starting at the cap with initialLimit: 2000, a truncated 2001-row response reports canLoadMore=false, loadMore() issues no request, and narrowing filters restarts at the first page under the same cap (passes with the change; the cap branch did not exist before).
• The existing "138 Projects use explicit bounded pages" test still passes, covering below-cap pagination and the filter reset.
• npx vitest run test-v2/progressive-loading.test.tsx: 7 passed; npm run typecheck: clean.

Compatibility

No API or data-shape changes: one new boolean on the hook's returned state and one view-level rendering condition.

[swjnxyf]

Reviewed the 2,000-project server cap, canLoadMore control, bounded pagination, filter resets, view rendering, and i18n fallback. No blocking code findings. The original failing frontend-contract job was only an outdated checked-in runtime-v2 app.js bundle. Integrated current main and regenerated it in follow-up 79a6585. On wkp, frontend typecheck and all seven progressive-loading regressions passed. Approving; no need to wait for an intermediate CI rerun before the maintainer's authorized merge.