chore(web): address Copilot review on #2128

Seven of the eight comments, plus the three suppressed ones (the same
double-cast class):

- Narrow the toast hooks to `InspectorClientEventSource`, the client's
  typed event-listener surface. A bare `EventTarget` cannot satisfy it
  (its listener takes an `Event`, the typed one a `TypedEventGeneric`
  with `detail`), so both tests now construct a real
  `InspectorClientEventTarget` and dispatch through `dispatchTypedEvent`
  rather than casting a stand-in. That failed to compile immediately and
  caught two bad fixtures: `task()` was a `Pick<Task, "status">` where
  the event map wants a full `Task`, and `toolCallTaskUpdated` was
  dispatched with no `task` at all.
- Narrow `useExportActions`'s three store parameters to the single
  clearing method each handler calls, so the test doubles are
  structurally checked instead of cast away.
- Build real `MessageEntry` fixtures (`timestamp` is a `Date`, not `0`),
  removing four more double casts.
- Fix a tautological assertion in useTabUiState.test: it compared a
  callback to itself, so it held however the identity changed. Every
  callback is now captured before the update and compared to those
  references.
- Reword `resetTabUiState`'s doc: `exhaustive-deps` cannot infer
  stability across a hook boundary, so the dependency IS named — the
  stability buys no churn, not omission.
- Justify the one remaining double cast in place, per the type-safety
  rule.

`useProgressToasts` still returns `void` rather than an object,
deliberately: it has nothing to return, and `{}` would imply an API that
is not there. Noted on the PR as the one deviation from #2128's
"returns one object" criterion.

Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/hooks/useProgressToasts.ts

@@ -1,9 +1,7 @@
 import { useEffect, useRef } from "react";
 import { notifications } from "@mantine/notifications";
-import type {
-  InspectorClient,
-  InspectorClientEventMap,
-} from "@inspector/core/mcp/index.js";
+import type { InspectorClientEventMap } from "@inspector/core/mcp/index.js";
+import type { InspectorClientEventTarget } from "@inspector/core/mcp/inspectorClientEventTarget.js";
 import type { TypedEventGeneric } from "@inspector/core/mcp/typedEventTarget.js";
 import {
   formatProgressToastMessage,
@@ -11,6 +9,20 @@ import {
   progressToastId,
 } from "../utils/toasts/progressToasts";
 
+/**
+ * The only part of the client the toast hooks touch: its typed event-listener
+ * surface. Naming that rather than the whole `InspectorClient` states the real
+ * dependency, and lets a test drive them with a plain
+ * `InspectorClientEventTarget` instead of a stand-in cast to a full client.
+ *
+ * Declared here (rather than in a module of its own) because it has no runtime
+ * half, and `useTaskToasts` — its only other consumer — is a sibling.
+ */
+export type InspectorClientEventSource = Pick<
+  InspectorClientEventTarget,
+  "addEventListener" | "removeEventListener"
+>;
+
 /**
  * Surface incoming `notifications/progress` as toasts so the user can watch a
  * long-running tool's progress while staying on the tool view — the v2
@@ -21,7 +33,9 @@ import {
  * (see `progressToastId`) and replaced per tick, so a chatty server updates one
  * toast rather than stacking one per tick.
  */
-export function useProgressToasts(inspectorClient: InspectorClient | null) {
+export function useProgressToasts(
+  inspectorClient: InspectorClientEventSource | null,
+) {
   // Which progress streams currently have a live toast. Entries are removed
   // when their toast closes (auto-dismiss or user). A ref (not state) because
   // it is incidental bookkeeping that must not trigger re-renders.