Desktop task counters are capped and can move backward after 200 issues

## Summary

In Buzz Desktop, **Work Queue → Tasks** computes `Tasks`, `Active`, and `Completed` from a repository issue query capped at 200 root events. Repositories with more than 200 issues therefore show incomplete, non-monotonic progress counters: creating a newer task can evict an older completed task from the newest-first relay window, making **Completed decrease**.

John hit this on the `ralph-queue` repository on 2026-08-28. Desktop showed:

- Tasks: 187
- Active: 92
- Completed: 95

At the same time, the authenticated CLI returned 306 unique issue roots with `--limit 1000`. The Desktop total was 119 short.

## Confirmed mechanism

Reviewed against `block/buzz` `origin/main` at `b49675894b39f87215e4dfc8c1ad4a3c28c6097e`.

`desktop/src/features/projects/hooks.ts`, `fetchProjectIssues`, requests:

```ts
relayClient.fetchEvents({
kinds: [KIND_GIT_ISSUE],
"#a": [project.repoAddress],
limit: 200,
});
```

The relay's canonical query order is newest-first (`created_at DESC, id ASC`; `crates/buzz-db/src/event.rs`). There is no pagination in this repository-detail loader.

`desktop/src/features/projects/ui/projectRightPanelContext.ts` then derives all three counters directly from that bounded array:

```ts
const completed = issues.filter(
(issue) => issue.status === "Done" || issue.status === "Closed",
).length;

return {
active: issues.length - completed,
completed,
total: issues.length,
};
```

`ProjectRepositoryActionsPanel.tsx` renders those values as Tasks / Active / Completed. The arithmetic is internally consistent for the loaded window, but the window is not the repository.

The observed 187 rather than exactly 200 is downstream reduction behavior within the capped response; it does not change the confirmed defect that the loader cannot return more than 200 roots.

## Reproduction evidence

Authenticated against the current Ricordo relay:

```text
buzz issues list ... --limit 1000 → 306 rows / 306 unique ids
buzz issues list ... --limit 300 → 287 rows / 287 unique ids
Desktop Tasks panel → 187 total
```

The CLI's separate 300-limit discrepancy may warrant its own pagination investigation. This issue is scoped to the confirmed Desktop 200-root cap and non-monotonic counters.

## Required outcome

The repository Tasks list and its Tasks / Active / Completed counters must represent the complete accessible issue set, not a newest-event window. Adding a new active issue must not make an older completed issue disappear from the list or decrement Completed.

Use bounded pagination/cursors rather than replacing 200 with a larger fixed cap. Preserve repository and community scoping and current status reduction semantics.

## Acceptance and negative control

Add a loader-level fixture containing 201 valid issue roots for one repository, with the oldest root closed.

- **Pre-fix negative control:** the existing loader returns at most 200 roots; the oldest closed issue is absent and the completed count is 0.
- **Fixed behavior:** the same fixture returns all 201 roots; `projectTaskActivity` reports total 201 and completed 1.
- Add one newer active root without changing any prior event. The result must become total 202, active +1, and completed must remain 1.
- Preserve an existing depth-under-200 fixture unchanged to prove no regression in ordinary repositories.
- Run the Desktop project-feature test suite and repository-required TypeScript checks with literal pass output recorded in the PR.

## Non-goals

- Do not change what `Done` or `Closed` means.
- Do not hide or discard superseded/closed issue roots to stabilize the number.
- Do not solve this by changing display copy or caching a previous count.
- Do not fold the CLI `--limit 300` discrepancy into this fix without a separate mechanism and test.

## Execution envelope

- **REVIEW BASE:** `b49675894b39f87215e4dfc8c1ad4a3c28c6097e`
- **EXECUTION BASE:** resolve current `origin/main` at pickup and prove base admissibility if it moved.
- **BUDGET:** one implementation plus one correction round.
- **TERMINAL:** success | blocked | exhausted.
- **RETURN:** exact SHA/diff, negative-control output, fixed fixture output, Desktop project-feature tests, TypeScript result.
- **ON CONFLICT:** stop and report; do not replace completeness with another fixed cap.

Start in desktop/src/features/projects/hooks.ts at fetchProjectIssues and then read desktop/src/features/projects/ui/projectRightPanelContext.ts and ProjectRepositoryActionsPanel.tsx to trace loading and counter reduction. Add the named 201- and 202-root fixtures, preserving the depth-under-200 case, then run the Desktop project-feature test suite and required TypeScript checks. Done means paginated results include every accessible root and Completed stays monotonic.

Written by the indexing model from the issue text.