Chat link_provider card shows 'Connect Google Calendar' on refresh when already connected

[ljagiello]

What

In a chat with a historical connect_service tool call, after the OAuth flow completes successfully and the page is refreshed, the embedded LinkProvider card re-renders as an active "Connect Google Calendar" CTA — even though the credential is connected and subsequent calendar tool calls in the same chat work fine.

Repro: chat chat_VjcXp8h3dx, see attached screenshot. Backend confirms /internal/v1/credentials/default/google-calendar returns 200 from 11:28:14 onward; the chat just keeps showing the old "isn't connected yet" copy + a live Connect button.

Why

Two reinforcing problems in tools/agent-playground/src/lib/components/chat/connect-service.svelte:

1. Component never reconciles connection state at mount. connected is initialized to false and only flips to true when the OAuth callback message fires in the current page session ($effect at line 100). On a fresh page load the listener can't fire — the OAuth dance already completed — so the card re-renders the active "Connect" state.
2. Persisted tool output is frozen. The assistant's tool-connect_service part in the chat stream stays { progress: { status: "active" } } forever. The successful OAuth arrives as a separate data-credential-linked user-message part rather than mutating the original tool call's output, so even an export/replay sees "still connecting."

tool-call-card.svelte:397-400 unconditionally mounts <ConnectService> whenever a connect_service tool call exists, regardless of whether the credential is now present.

Fix idea

Smallest safe fix: in connect-service.svelte's mount $effect, also query Link for current credential status (e.g. GET /v1/summary or a per-provider check) and set connected = true if the credential already exists — reusing the existing "✓ {provider} connected" success state.

Larger follow-up: update the persisted tool-call output when the credential-linked event arrives, so chat history/export is internally consistent.

[LissaGreense]

There's an inverse-symptom case on the delete side that shares the same observable shape — flagging while we're looking at #325 in case we want to fix both at once.

The symmetry:

• Add-side (this issue): OAuth completes → Link has the credential → chat's ConnectService card still renders "Connect …" on refresh. UI didn't learn the credential now exists.
• Delete-side: OAuth credential is deleted → atlasd's mcp-tool-cache still serves the 31 tools it cached while the credential was live. Cache didn't learn the credential is gone.

Delete-side repro:

# Connected, tools list returns 31
curl -sk https://localhost:8080/api/mcp-registry/com-atlassian-atlassian-mcp-server/tools | jq '.tools | length'
# → 31

curl -sk -X DELETE https://localhost:8080/api/link/v1/credentials/<id>

# No credential to fetch with, but cache is stale
curl -sk https://localhost:8080/api/mcp-registry/com-atlassian-atlassian-mcp-server/tools | jq '.tools | length'
# → 31  (wrong)

Where it dies on the delete side: Link's DELETE handler at apps/link/src/routes/credentials.ts:296-355 revokes the OAuth token, deletes the row, returns 204 — no callback, no publish, no atlasd notification. atlasd's cache-invalidation call sites in apps/atlasd/routes/mcp-registry.ts:642, 660, 730, 973, 1016 are all driven by workspace-config / server-install lifecycle. None are driven by credential lifecycle.

Both sides look like instances of the same gap: credential lifecycle events don't propagate to UI/cache consumers. If we want to land a single fix that closes both, the natural shape is something Link-side that emits on credential add/delete (NATS subject, HTTP callback, whatever fits) — the chat ConnectService card subscribes for add, atlasd's mcp-tool-cache subscribes for delete.