fix(ui): stop error toast spam and stuck spinner for stale pod rows

[pujitha24]

What type of PR is this?

/kind bug

What this PR does / why we need it:

On the topology view, expanding a ReplicaSet's Pod table renders one PodStatusCell per row, each polling /rest-api/v1/insight/summary for that pod's live status. When a pod is still present in the search index but has already been deleted from the live cluster (a maintainer-acknowledged, expected transient inconsistency between the search index and the cluster, per the discussion on the linked issue), that call returns {success:false, message: "pods \"X\" not found"} over HTTP 200.

Today every such row triggers a disruptive global error toast, and the row's status cell is left spinning forever, because the shared useAxios hook's handleResponse never updates its response state on a failed /rest-api call -- it only fires the notification and returns, so callers can't distinguish "still loading" from "request finished but failed".

This PR adds an opt-in silentError option to useAxios (default false, so every other existing call site is unaffected). usePodStatus passes silentError: true and now distinguishes "no response yet" (stays "Loading") from "response arrived but failed" (resolves to "Unknown", a status value already recognized by PodStatusCell's existing color mapping).

This does not address the underlying search-index/cluster staleness itself (a separate, harder problem the maintainer is still investigating on the issue thread); it only makes the UI degrade gracefully -- no error-toast spam, no stuck spinner -- when that staleness is encountered.

Validation: This sandbox's disk was exhausted at the OS/container level (confirmed via df -h, unrelated to this repo), so npm install/npm run lint/npm run build could not be run here. Instead, a standalone dependency-free node -e script mirroring the exact branch logic added to both handleResponse and usePodStatus's status resolver was executed directly, asserting: existing (non-opted-in) callers keep notifying and skip setResponse on failure exactly as before; the new silentError: true path skips the notification but still resolves response; and the three-way status resolution (no response -> Loading, success -> resolved status, failed response -> Unknown) behaves as intended. All assertions passed. Flagging this plainly since it's a logic-equivalence check, not an in-app or CI run -- happy to re-verify with npm run lint/npm run build if CI or a reviewer surfaces anything.

Which issue(s) this PR fixes:

Fixes #767

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[pujitha24]

I have read the CLA Document and I hereby sign the CLA

[pujitha24]

recheck