fix(jianyu): stabilize search and add detail extraction contract

[leozejia]

Summary\n- Harden jianyu search against anti-bot/API drift with a fallback chain (API -> DOM -> public index).\n- Add jianyu detail command for structured detail extraction.\n- Add retry handling for transient page-context failures and empty-result retries.\n- Scope procurement shared helpers under clis/jianyu/shared instead of clis/_shared.\n- Update Jianyu adapter docs with search/detail contract.\n\n## Why\nJianyu search often returns empty or unstable results under anti-verify conditions. This improves result continuity and provides a structured detail path for downstream workflows.\n\n## Validation\n- npm run test:adapter -- clis/jianyu/search.test.ts clis/jianyu/shared/procurement-contract.test.ts clis/jianyu/shared/procurement-detail.test.ts\n- npm run typecheck

[hiSandog]

One thing that looks risky in fetchJianyuApiRows() in clis/jianyu/search.ts: the per-type loop stops as soon as rows.length >= limit, but the real quality gate (filterNavigationRows() + dedupeCandidates()) only runs later in the command handler.

That means duplicates or navigation-ish rows from earlier fType / eType buckets can consume the budget and prevent later unique rows from ever being considered. In practice jianyu search --limit N can end up returning fewer than N results even when more unique matches exist in the later buckets.

The previous adapter kept the safer shape of dedupe first, slice last. I would collect all normalized API rows (or at least over-fetch per bucket), then run navigation filtering + dedupe + final slice(limit) once at the end.