Duplicate tool names: the second copy still cannot be selected or inspected — #1961 fixed rendering but not selection identity #2001

Found by Copilot reviewing the v2.2.0 milestone merge (#1993), verified against the code. Follow-on to #1957 / #1961.

#1961 fixed the rendering half of the duplicate-tool-name problem: rows are now keyed by source position, so filtering no longer orphans a child during reconciliation. But everything downstream of the key still identifies a tool by tool.name, so a tools/list that repeats a name is still not fully inspectable:

• clients/web/src/components/groups/ToolControls/ToolControls.tsx:170 — selected={tool.name === selectedName}, so both duplicates highlight at once.
• :172 — onClick is guarded by if (tool.name !== selectedName), so once either copy is selected, clicking the other is a no-op.
• clients/web/src/components/screens/ToolsScreen/ToolsScreen.tsx:165-166 — tools.find((t) => t.name === selectedToolName) always resolves to the first match, so the detail panel can never show the second copy even if selection did change.

Net: with duplicate-tool-names-http.json loaded, the second get_weather / echo renders in the sidebar (that part now works) but cannot be opened. Two tools with the same name and different schemas are indistinguishable in the UI.

Expected

Each rendered row is independently selectable, and the detail panel shows that row's tool.

Suggested shape

Thread the same stable per-row identity ToolControls already computes for key through selection state — selectedToolKey rather than selectedToolName — in ToolControls, ToolsScreen's ui state, and the tools.find(...) lookups (:166 and :174).

onCallTool must keep sending the protocol name (selectedTool.name, ToolsScreen.tsx:260) — the wire identity is genuinely the duplicated name, and only the UI identity needs to be unique.

Repro

test-servers/configs/duplicate-tool-names-http.json, default (legacy) era. Click the trailing get_weather row after selecting the leading one.