refactor: consolidate duplicate bounded-concurrency helpers onto mapWithConcurrency (#6602)

[jaytbarimbao-collab]

Closes #6602.

src/queue/map-with-concurrency.ts's mapWithConcurrency is the canonical bounded-concurrency worker-pool helper, but two hand-duplicated copies of the same loop had drifted in beside it (visible in processors.ts, which imports both):

• src/signals/focus-manifest-loader.ts — exported mapWithConcurrencyLimit
• src/queue/patchless-secret-scan.ts — private mapPatchLessSecretScanFilesWithConcurrency

Both now delegate to mapWithConcurrency, preserving their names and (items, limit, mapper) signatures so every caller compiles and behaves unchanged. After this, map-with-concurrency.ts is the only file under src/queue/ or src/signals/ implementing the loop itself. Pure internal consolidation — no public behavior, signature, or export-name change.

Tests / coverage: no new test needed per the issue — both wrappers are exercised transitively by existing suites (test/unit/patchless-secret-scan.test.ts 54 tests incl. the patch-less fallback path; focus-manifest-loader + processors suites drive mapWithConcurrencyLimit). Verified green (89 tests) and tsc clean on current main; the changed delegation lines are covered.

(Resubmit of #6718, which was auto-closed as collateral while main was briefly tsc-broken by an unrelated duplicate import in src/api/routes.ts — now fixed. The change itself is unchanged and was reviewed as "a straightforward consolidation.")

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.65%. Comparing base (3de7c25) to head (b9de572).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6727      +/-   ##
==========================================
- Coverage   93.65%   93.65%   -0.01%     
==========================================
  Files         682      682              
  Lines       68133    68117      -16     
  Branches    18701    18701              
==========================================
- Hits        63808    63792      -16     
  Misses       3347     3347              
  Partials      978      978              

Flag	Coverage Δ
shard-1	43.88% <100.00%> (-0.09%)	⬇️
shard-2	36.92% <100.00%> (+0.07%)	⬆️
shard-3	32.37% <0.00%> (+0.06%)	⬆️
shard-4	34.24% <50.00%> (-0.61%)	⬇️
shard-5	31.42% <50.00%> (+0.40%)	⬆️
shard-6	45.78% <50.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/patchless-secret-scan.ts	100.00% <100.00%> (ø)
src/signals/focus-manifest-loader.ts	95.76% <100.00%> (-0.27%)	⬇️

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-17 04:50:42 UTC}

2 files · 1 AI reviewer · no blockers · readiness 88/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a straightforward internal refactor that replaces two hand-duplicated bounded-concurrency loops in focus-manifest-loader.ts and patchless-secret-scan.ts with delegation to the canonical mapWithConcurrency helper, preserving both wrapper functions' names and (items, limit, mapper) signatures so all existing call sites remain unchanged. The diff is well-scoped, ties to issue #6602, and CI (including tsc and existing test suites) passed on the commit, giving reasonable confidence the delegation is call-compatible. No new tests were added, but the PR's rationale that the two wrappers are already exercised transitively by existing suites is credible given the signature is preserved byte-for-byte.

Nits — 5 non-blocking

• No direct unit test asserts mapWithConcurrencyLimit/mapPatchLessSecretScanFilesWithConcurrency now delegate to mapWithConcurrency rather than just verifying end-to-end behavior — a quick spy/mock assertion in patchless-secret-scan.test.ts or focus-manifest-loader tests would make the consolidation itself regression-proof if mapWithConcurrency's contract ever changes.
• The `Consolidate duplicate bounded-concurrency map helpers in src/queue and src/signals #6602` issue reference embedded in the new JSDoc comments (src/signals/focus-manifest-loader.ts:239, src/queue/patchless-secret-scan.ts:158) is fine as inline documentation but isn't a named constant — purely stylistic, not worth changing.
• Consider a small delegation-only test (mock mapWithConcurrency and assert the wrapper forwards items/limit/mapper unchanged) to lock in the consolidation contract independent of the higher-level suites.
• If mapWithConcurrency in src/queue/map-with-concurrency.ts has a different concurrency-throttling signature (e.g., an optional resolveLimit param) than what's shown in the loopover-miner package's same-named helper, double check the two are not confused in future refactors — worth a one-line comment distinguishing them if they diverge.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6602
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 173 registered-repo PR(s), 90 merged, 4 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jaytbarimbao-collab; Gittensor profile; 173 PR(s), 4 issue(s).
Improvement	ℹ️ None detected	risk: low · value: none

Review context

• Author: jaytbarimbao-collab
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Rust
• Official Gittensor activity: 173 PR(s), 4 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review