History: server notifications show a permanent PENDING status badge

[cliffhall]

Problem

In the History screen, a server-sent notification (e.g. notifications/message) is shown with a PENDING status badge that never resolves. See screenshot below — a stdio everything-server log notification stuck on "Pending".

This is purely a display bug; the notification was delivered fine. It is transport-independent (stdio/HTTP/SSE all affected).

Cause

extractStatus in clients/web/src/components/groups/HistoryEntry/HistoryEntry.tsx:76 derives the badge from whether a response is attached:

function extractStatus(entry: MessageEntry): "success" | "error" | "pending" {
  if (!entry.response) return "pending";
  if ("error" in entry.response) return "error";
  return "success";
}

But the pending → OK/Error lifecycle only applies to requests. messageLogState only attaches .response to entries with direction: "request" (correlated by JSON-RPC id; see core/mcp/state/messageLogState.ts:77-95). A notification is fire-and-forget — no id, no response, ever — so entry.response is permanently undefined and the entry is labelled Pending forever. The same mislabel hits any standalone direction: "response" entry (an unmatched response).

MessageEntry already carries direction: "request" | "response" | "notification" (core/mcp/types.ts:171); extractStatus ignores it.

Proposal

Scope the request lifecycle to direction === "request". For non-request entries (notifications, standalone responses), render no status badge (the method badge — e.g. NOTIFICATIONS/MESSAGE — already labels them), rather than a misleading Pending/OK/Error chip.

function extractStatus(entry: MessageEntry): "success" | "error" | "pending" | "none" {
  if (entry.direction !== "request") return "none";
  if (!entry.response) return "pending";
  if ("error" in entry.response) return "error";
  return "success";
}
// render the status Badge only when status !== "none"

Acceptance criteria

• A notification entry shows no Pending badge (no request-style status badge at all).
• A request still shows Pending (no response yet) → OK / Error once its response is correlated.
• A standalone response entry isn't shown as Pending.
• Tests cover the notification (no badge) and request (pending → OK/Error) cases.