NotificationReadinessCard collapses loading and error into one plain-text branch

[JSONbored]

Context

apps/loopover-ui/src/components/site/notification-readiness-card.tsx:115-121 collapses its loading and error states into one plain-text branch:

<p className="mt-3 text-token-sm text-muted-foreground">
  {model.status === "loading"
    ? "Loading notification model…"
    : "Notification model unavailable."}
</p>

useApiResource (imported at the top of this file) already exposes errorKind/error on failure, but this component discards them — an actual fetch error and "still loading" render identical generic copy, and there's no retry action, unlike the shared LoadingState/ErrorState components (apps/loopover-ui/src/components/site/state-views.tsx) used elsewhere in this app for the same distinction.

Requirements

• Replace the collapsed loading/error branch with LoadingState for the loading case and ErrorState for the error case, both imported from @/components/site/state-views.
• Pass useApiResource's actual error/errorKind through to ErrorState instead of the generic "Notification model unavailable." string.
• Preserve the existing success-path rendering (the privacyGuards list) unchanged.

Deliverables

• Loading branch uses LoadingState
• Error branch uses ErrorState with the real error surfaced
• Test covering loading, error, and success render paths

Test Coverage Requirements

apps/** UI code falls outside this repo's strict Codecov patch gate (check coverage.include) — a before/after screenshot is still required per this repo's UI-PR convention, plus the regression test above.

Expected Outcome

A real fetch failure is visibly distinguishable from "still loading," with the actual error surfaced, matching how the rest of the app already handles useApiResource failures.

Links & Resources

apps/loopover-ui/src/components/site/state-views.tsx — LoadingState/ErrorState definitions. apps/loopover-ui/src/lib/api/use-api-resource.ts — the errorKind/error fields this issue wires through.

[linear-code]

JSO-4750