fix(client): coalesce catalog refetches from event bursts

[Hona]

A Desktop netlog showed GET /api/mcp fetched 192 times in a 7 s window: 9–10 times per directory, median gap ~70 ms, for ~20 directories. The server emits one mcp.status.changed per MCP server as each one settles, and createData answered every event with invalidate + sync, so a location with nine MCP servers cost nine identical refetches. Each of those also paid a CORS preflight, and together they tripped [server-request-queue] server thrashing detected.

flowchart LR
  subgraph before [Before]
    E1[mcp.status.changed × N] --> R1[N × GET /api/mcp]
  end
  subgraph after [After]
    E2[mcp.status.changed × N] --> S[invalidate now, refetch after 150 ms quiet] --> R2[1 × GET /api/mcp]
  end

Loading

Changes — packages/client/src/solid/data.ts

• Settle window for event bursts. settle(key, load) invalidates immediately (so an explicit sync() during the window still reads fresh) and runs one refetch once the burst has been quiet for settleMs = 150. Applied to mcp.status.changed, the only event the server emits once per member of a list.

case "mcp.status.changed":
  result.location.mcp.server.invalidate(location)
  settle(`mcp.status:${locationKey(location)}`, () => result.location.mcp.server.sync(location))
  break

• Queued reloads absorb later invalidations. createSync chains a reload behind an in-flight load when the key is invalidated mid-read. That reload has not read anything yet, so an invalidation arriving before it starts is already covered; marking it invalidated only chained a third, fourth, … load behind it. Pending.started now gates invalidated, capping any burst at one in-flight load plus one queued reload for every key, not just MCP.

// before: 3 invalidations while loading → 3 chained reloads
// after:  3 invalidations while loading → 1 chained reload

Companion to #47443, which stops refetching catalogs for locations this client never read. This PR bounds the refetch rate for locations it did read.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.