Partial Radius inventory failures are silently presented as complete results

Bug information

Steps to reproduce

1. Open an applications or environments list while both the Applications.Core and Radius.Core namespace requests are enabled.
2. Make one namespace request succeed and the other fail, for example with a 403, 404, or unavailable upstream.

Observed behavior

RadiusApiImpl.listMultipleTypes() uses Promise.allSettled(), merges fulfilled results, and throws only when every request fails. When one namespace fails, the caller receives an ordinary successful { value: [...] } result with no indication that the inventory is partial and no retry path. A failed discovery can therefore be presented as a complete or empty list.

Desired behavior

Return an explicit partial-result state that identifies failed branches and supports retry. Loading, empty, partial, stale, and error must remain distinguishable; authorization failures must not trigger an automatic connection switch.

Workaround

There is no UI workaround. Operators must inspect network requests to discover that part of the inventory failed.

Additional context

Discovered while implementing Phase 2 error requirement ER-08 in docs/design/2026-09-dashboard-plugin-test-plan.md. A characterization test will pin the current silent-partial behavior until this issue is fixed.

Would you like to support us?

• Yes, I would like to support you

Start at RadiusApiImpl.listMultipleTypes() and read ER-08 in docs/design/2026-09-dashboard-plugin-test-plan.md, then review the characterization test referenced in the issue. Done means failed branches are identified with a retry path, loading, empty, partial, stale, and error states remain distinct, and authorization failures do not trigger an automatic connection switch.