[codex] test(server): make bounds-cache test synchronous (BLO-21754)

[kkroo]

Thinking Path

• Paperclip is the control plane for autonomous AI companies, and reliable server verification is necessary for safe changes to that control plane.
• The compact issue-list route maintains a bounded server response cache, whose eviction behavior is covered in issue-list-assignee-filter-routes.test.ts.
• The former bound test drove 261 sequential HTTP requests through Express and embedded Postgres just to exercise the cache trim path.
• That async setup timed out on loaded runners and could emit a misleading second assertion from a partially populated cache.
• Current master still has that loop, while App PR test(server): stop bounds-cache test from driving 261 sequential HTTP round trips (BLO-21754) #1039 and an unpublished kkroo candidate contain the direct synchronous approach.
• This independently authored draft applies the minimal two-file fix on current master: seed entries through the same production cache mutation path and assert the real bound.

Linked Issues or Issue Description

The issue is Paperclip-tracked as BLO-21754. Refs #1039: the App-authored original cannot supply the required independent review path. The test previously made 261 sequential HTTP round trips and could time out before finishing its assertion.

What Changed

• Added a test-only passthrough to setIssueListResponseCacheEntry, the production insert-and-trim path.
• Replaced the asynchronous HTTP/database loop with synchronous synthetic cache entries while retaining the real 256-entry bound assertion.
• Kept the change to server/src/routes/issues.ts and its focused route test only; pnpm-lock.yaml is unchanged.

Verification

• Ran pnpm --filter @paperclipai/server exec vitest run src/__tests__/issue-list-assignee-filter-routes.test.ts --reporter=verbose: 14/14 passed; the bounds-cache test took 24ms.
• Ran pnpm --filter @paperclipai/server typecheck.
• Ran git diff --check.

Risks

Low risk: production cache behavior and its 256-entry constant are unchanged. The helper delegates directly to the existing production insertion path, and the test remains an eviction regression check without asynchronous shared-state exposure.

Model Used

OpenAI GPT-5 via Codex, with terminal tooling for PR comparison, isolated implementation, and local verification. The host does not expose a separate context-window value.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
• I have searched GitHub for duplicate or related PRs and linked them above
• I have described the BLO-21754 issue in-PR and referenced the related pull request
• I have run tests locally and they pass
• I have updated the focused regression test
• This change does not affect the UI
• Documentation update is not applicable to this test-only change
• I have considered and documented the low risk
• All Paperclip CI gates are green (pending this exact draft head)
• Greptile is 5/5 with no open P2s, recommendations, or follow-ups (pending exact-head review)
• I will address all reviewer comments before requesting merge

[allyblockcast]

🔗 Paperclip issue: BLO-21754

[allyblockcast]

🔗 Paperclip issue: BLO-21754

[kkroo]

Closing as stale — this draft can no longer be landed as a diff.

Measured against master ac91e966:

• 802 commits behind
• 1 conflicting file(s) (git merge-tree --write-tree)

At that distance the surrounding code has moved out from under the patch, so "resolve the conflicts" would mean rewriting it against a codebase it was never written for — not merging it. Reopening is cheap if the branch is still wanted; the commits are untouched.

Closing the PR does not close the underlying issue. Where this PR referenced a BLO issue, that issue remains the record of intent and the place to re-implement from, against current master.

No judgement here on whether the original problem still exists — I did not verify that per-PR, and it should be re-checked before any re-implementation, since some of these may already have been fixed independently.