Thanks, and sorry for the wait. Queued for review.

Mechanically in good shape: MERGEABLE with 28 checks green, +95/-12 across two files.

Project discovery scalability has come up from a few directions recently, so a targeted fix there is welcome.

An update on this one, and an apology for how long it has sat.

Half of your PR has just shipped — and you found the bug independently, which deserves saying plainly.

The yyjson_mut_obj_add_str → add_strcpy fix for the coverage scope field landed on main tonight in f18ed73 (via #1148). Your diagnosis and @aaiyer's were the same and both correct: scope is declared inside the yyjson_arr_foreach body and was being stored by pointer, so by serialization time every entry aliased one dead, reused stack slot — multi-scope check_index_coverage responses returned the last label for all entries, on top of stack-use-after-scope UB. Two people finding the same non-obvious bug from different directions is a good signal it was worth fixing, and you were first to report it here.

The practical consequence is that main now contains that exact line, so this branch will conflict on it.

What is still live in this PR: the list_projects pagination. That part has not shipped and is not duplicated. It is with the maintainer, because it changes the default contract of a public MCP tool — today list_projects returns every project with nodes/edges/size/branch, and this makes the default 50-capped and detail-less with the rest behind include_details. metadata_only=true stays compatible, but the old default does not, so existing consumers would silently lose fields. That is a findability-versus-cost decision on a public surface and it is genuinely his call, not mine. The underlying problem you are solving is real — opening 632 project databases to answer one list request is not defensible.

Two defects worth fixing regardless of which way that decision goes:

1. qsort(db_names, 0, …) is called with db_names == NULL when the cache holds no .db files. Passing a null pointer to qsort is undefined behaviour even with a zero count — this is the exact class we just fixed elsewhere in the tree (pass_similarity calls qsort with a null base for an empty fingerprint set #1367/fix(similarity): skip empty fingerprint sort #1368), so it is worth guarding.
2. A realloc/strdup failure currently breaks out of the loop, which produces a truncated list alongside a total/has_more computed for the full set. The caller cannot tell a short answer from a complete one, which is worse than failing outright.

What would help most right now: rebase on current main and drop the add_strcpy hunk (it is already there), leaving this PR as purely the list_projects change. That makes the remaining decision a clean one and gets rid of the conflict.

Thank you for the report and for the fix — the scope bug was corrupting output from a tool we ship and our own tooling calls, and it is genuinely better for having been caught twice.

Rebased on current main and removed the now-duplicated coverage-scope production change and tests, so this PR is now purely the list_projects pagination change.

I also addressed both defects from the review:

• empty caches no longer call qsort with a null base;
• realloc/strdup failure now frees partial state and returns an explicit MCP error instead of a truncated successful response with inconsistent total/has_more.

The pagination tests now cover deterministic page order, the second page, metadata_only=true, and include_details=true. The final signed-off head is 434b319f, and the PR description now reflects only the remaining live change. Full CI is running.

Thank you for the focused follow-up: removing the duplicated scope, tightening allocation and sort handling, and narrowing the PR to pagination. I have recorded those changes and returned the current diff to the maintainer review queue. Detailed feedback may take a little time while the community queue is full.

Rebased this PR onto current upstream main (7f23a66a, v0.10.2+) and force-updated the head with lease protection.

• new head: d695771d
• scope remains only deterministic/paginated list_projects with opt-in details
• git diff --check: clean
• Windows production GCC build: GREEN (A5608EA18D4D5D2E579A90D7410ED3A0E05FC24BE9EF000E587A4E1258B715E5 for the combined updated-base candidate)
• focused native suites on the updated base (mcp lang_contract): 224 passed, 7 platform skips

Local GCC 15 required suppressing two unrelated warnings-as-errors in existing daemon tests (free-nonheap-object, stringop-overflow) to reach the focused suites; no source suppression was committed. Fresh CI on this exact head is the authoritative pinned-toolchain result.

CI follow-up: I inspected the failing Windows shard 2/2 log. The PR code did not fail. All 32 preceding scheduler-contract cases passed, then the upstream parallel-scheduler self-test flaked at hang_after_summary with suite leader exited leaving live descendants and exited 2 before writing shard-manifest.txt; shard-completeness and ci-ok were therefore cascade failures.

The branch was already exactly one focused commit over current main (7f23a66a) with no new upstream commits to rebase. I refreshed the same signed-off content under head a62c6788 solely to trigger a clean CI rerun. If the scheduler failure repeats, I will keep its infrastructure fix separate from this list_projects PR.

CI update: the fresh run on a62c6788 is now fully green, including shard completeness and Windows CLANG64 2/2. This confirms the earlier failure was the unrelated parallel-scheduler cleanup flake described above; no product change beyond the focused list_projects fix was needed.

Thank you @tmonestudio for the clean rerun and the attribution note. The current head a62c6788 is mergeable and fully green, including the Windows shard and completeness gate, with the diff still limited to deterministic/paginated list_projects and opt-in details.

This is recorded back in the maintainer review queue. The queue is still full, so detailed review may take some time; no further triage action is needed from you now.

Merged — thank you! Pagination with a lean default was the right call for real fleets (632 DBs at >60s was unanswerable before), and removing the #1148-overlap hunk promptly when asked made this easy to trust. The offset/limit+has_more shape is accepted as-is; if we later converge the tool family on nextCursor, we'll migrate this alongside the others rather than bouncing it back to you.