fix(discovery): raise maxScanCount default and sort before slice

[uibeka]

Problem

discover_agents(limit=50) silently returns only 20 agents despite 22,000+ agents registered on-chain. Additionally, when more agents are scanned than the limit, the returned subset may not contain the most recently registered agents.

Root Cause

1. maxScanCount silently clamps the user's limit (types.ts)

DEFAULT_DISCOVERY_CONFIG.maxScanCount is set to 20. In discoverAgents(), the limit is clamped via Math.min(limit, cfg.maxScanCount) before being passed to the event scanner. This makes the user-specified limit parameter ineffective above 20 — discover_agents(limit=50) passes 20 to the scanner, which breaks early at 20 logs and slices to 20 results.

2. .reverse().slice() selects wrong agents after paginated collection (erc8004.ts)

PR #228 introduced paginated backward scanning — chunks are collected newest-first, but eth_getLogs returns ascending order within each chunk. .reverse() on the concatenated array doesn't produce true descending order across chunk boundaries. .slice(0, limit) then selects from the wrong end. The existing post-slice .sort() corrects final ordering but can't recover agents discarded by the slice.

Fix

1. Raise maxScanCount from 20 to 100

The scan loop already has robust safeguards: per-chunk timeouts (PER_CHUNK_TIMEOUT_MS), consecutive failure limits (MAX_CONSECUTIVE_FAILURES), and an overall 60-second discovery timeout. These make a low scan count cap redundant. Raising to 100 allows meaningful discovery calls while retaining the safety net.

2. Sort by tokenId descending before .slice(0, limit)

Replace the .reverse().slice().sort() chain with .sort().slice(). Since ERC-8004 tokenIds are monotonically increasing on mint, sorting by tokenId descending before slicing ensures the newest agents are selected and correctly ordered regardless of chunk collection order.

Impact

• discover_agents(limit=50) returns up to 50 agents (previously silently capped at 20)
• Returned agents are the most recently registered (previously could include older agents from wrong chunk order)
• No performance regression — scan loop safeguards unchanged
• Backward compatible — callers passing limit ≤ 20 see identical behavior

Testing

• pnpm build — zero errors
• pnpm test — all existing tests pass

---

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.