fix(mcp): list_issues and list_projects collide between the unified server and mcp-track

[BryanFRD]

Problem

Two tool names are registered by two different servers with different schemas:

Tool	Server	Location	Arguments
list_issues	@ferrlabs/mcp	packages/mcp/src/tools/issues.ts:26	org_slug + project_slug
list_issues	@ferrlabs/mcp-track	packages/mcp-track/src/tools/issues.ts:24	project_slug
list_projects	@ferrlabs/mcp	packages/mcp/src/tools/orgs.ts:38	org_slug
list_projects	@ferrlabs/mcp-track	packages/mcp-track/src/tools/projects.ts:17	project-scoped

The two also hit different APIs — api.ferrlabs.com for the unified server, the FerrTrack base for the sub-MCP (packages/mcp-track/src/api-base.ts).

Why it matters

The README's recommended setup is to register the unified server alongside the sub-MCPs the user needs. A client with both ferrlabs and ferrlabs-track connected sees two tools with identical names, near-identical descriptions, incompatible arguments, and different backends. Which one an assistant picks depends on the client's dedup or prefixing behaviour, which varies. The user gets results from the wrong product with no error.

Proposed approach

Pick one and apply it consistently:

• Rename the FerrTrack ones (list_track_issues / list_track_projects) — matches the existing search_track / list_track_users naming already used in packages/mcp-track/src/tools/search.ts.
• Or drop the FerrTrack-shaped duplicates from @ferrlabs/mcp and leave issue/project listing to the sub-MCP.

Whichever way, add a check that fails CI when two packages register the same tool name — the collision set is cheap to compute from the registration modules and this will recur as the sub-MCPs grow.

Acceptance criteria

• No tool name is registered by more than one package.
• The README tool tables reflect the final naming.
• A test or CI step fails on a reintroduced collision.