[refactor] 兩支 resolver 的共用面：先判斷值不值得抽象，再決定合併

[kiki830621]

Problem

plugins/harness-devtools/scripts/ 底下有兩支各自獨立實作同一個形狀的 resolver：

	resolve-mcp-project.sh	resolve-marketplace.sh
搜尋根	MCP_ROOTS_SPEC="Developer/che-msg:any Developer/che-mcps:any Developer:mcp-suffix"	MARKETPLACE_SEARCH_ROOT（~/Developer，掃 */.claude-plugin/marketplace.json）
身分判準	目錄名（含 mcp-suffix 這類 pattern）	manifest 自報的 name
候選契約	mcp_project_candidates	marketplace_candidates（#20 新增，刻意對齊前者）
多重命中	warn + 說明 precedence 與修法	同左

四項裡三項是同一套機制的兩份寫法，只有「身分判準」真正不同。

為什麼是 residue 而不是當時就做

#20 的範圍是把 marketplace 端從硬編列舉換成發現法。合併兩支 resolver 是更大的重構，塞進同一個 change 會讓 review 分不清哪個改動修了哪個缺陷——這正是 #20 刻意把 #18 排除在外的同一條理由。

要注意的不對稱（不是單純的 DRY 練習）

身分判準的差異是真的，不是巧合。 #20 實測：marketplace 的 name 與目錄名 13/33 不同（bestasr 住在 bestASR-project/bestASR、livedocs-marketplace 的 name 是 livedocs）。所以目錄名對 marketplace 是錯的判準。

反過來，MCP project 沒有等價的 manifest 自報名稱可讀，mcp-suffix 這類 pattern 是它現有的判準。

合併前必須先回答：抽出來的共同 primitive 要把「身分判準」做成什麼形狀的參數？ 若答案是「傳一個 callback」，那共用的其實只剩走訪與 warn 兩件小事，抽象的收益可能低於它的成本。這個問題沒答之前不該動手。

Expected

先做判斷、再決定要不要做：

• 盤點兩支的實際共用面（走訪、候選契約、warn、快取策略），量化重複行數
• 決定身分判準的參數化形狀，或判定「不值得抽象」並記錄理由
• 若決定合併：單一 primitive + 兩個薄 adapter，兩支的既有測試全部續綠

判定「不做」也是合法結果，但要有寫下來的理由。

Actual

兩份實作各自演化。#20 在新增 marketplace_candidates 時是手動對齊 mcp_project_candidates 的契約——手動對齊會漂移。

Source: residue from #20 at /idd-close time (Step 3.6)