Multi-store fleets: each Darling MCP server is silent about its siblings — an agent cannot know which box answers for which servers #2339

Raised by Erik while reviewing the #2296 split (and about to get worse with a third, PostgreSQL-only box):

i'm also interested in how the darling mcp handles having two destinations on each box now. how do agents know which to use?

Today's behavior

Each box's MCP server exposes the same ~101 tool names over ITS store only. list_servers answers with that store's registry; a server monitored by a sibling box simply resolves as not-found, indistinguishable from a server nobody monitors. Nothing in the instructions, list_servers, or any error names the split — so an agent connected to the use2 endpoint asking about prod-sql-use1-beta-01 gets 'unknown server' when the true answer is 'the use1 box has that one.' With the fleet split by design (primaries in-region on use1, replicas in-region on use2, PostgreSQL heading to a third box), that's now the normal case, not an edge.

Fix shape, two tiers

1. Cheap, ships first — declared peers. A peers block in config (name + what-it-covers, no credentials): the MCP instructions gain a paragraph ('THIS store monitors the 42 use1 primaries; prod-sql-use2-monitor-01 monitors their readable replicas; …'), list_servers gains a peer_fleets summary, and the server-resolution miss message changes from 'unknown server' to 'not monitored HERE — matches the declared coverage of .' No cross-store connectivity, purely disclosure — an agent picks the right endpoint or tells its human which one to point at.
2. Later, maybe — federation. Actual cross-store reads (one endpoint proxying to peers). Much bigger surface (auth between stores, latency, partial failures) and possibly never worth it if tier 1 makes the split legible.

Tier 1 also documents itself into the census pin naturally (the instructions text is already inventory-pinned).