Admin Workspace page fails entirely when instances.get API returns an error

Description:

The Admin → Workspace page (/admin/info) fails to load completely when the
/api/v1/instances.get API request returns an error, even though other required
admin-related API requests succeed.

This results in a generic "Error loading pages" message being shown for the
entire Workspace page.

---

Steps to reproduce:

1. Run Rocket.Chat in a local/development environment
2. Log in using an Admin account
3. Navigate to Administration → Workspace (/admin/info)
4. Open browser DevTools → Network tab
5. Reload the page and observe the API requests

---

Expected behavior:

• Sections whose API requests succeed should still render
• The UI should degrade gracefully if one endpoint fails
• The Instance section could display a localized error message
  (e.g. "Instance information unavailable")
• The entire page should not fail due to a single endpoint error

---

Actual behavior:

• The whole Workspace page shows "Error loading pages"
• No indication is provided about which API request failed
• No partial rendering occurs even though other APIs return successful responses

---

Server Setup Information:

• Version of Rocket.Chat Server: 8,1
• License Type: Community
• Number of Users: <5
• Operating System: Windows (WSL2).
• Deployment Method: Tar / source.
• Number of Running Instances: 1
• DB Replicaset Oplog: Disabled
• NodeJS Version: 22.16.0
• MongoDB Version: 6.0.5

---

Client Setup Information

• Desktop App or Browser Version: Chrome (latest)
• Operating System: Windows (WSL2).

---

Additional context

When accessing /admin/info, the following API responses are observed:

• /api/info → 200 OK
• /api/v1/statistics?refresh=false → 200 OK
• /api/v1/instances.get → 400 Bad Request

A single failing request (instances.get) causes the entire Workspace page to
error, instead of isolating the failure to the relevant section.

On local, development, or self-hosted setups, instances.get may legitimately
fail, and the frontend should handle this scenario gracefully.

---

Relevant logs:

Browser (Network):

• GET /api/v1/instances.get → 400 Bad Request

I’d appreciate any feedback. I’d also be happy to work on a fix if this approach makes sense.

Start at the Admin Workspace entry point, /admin/info, and trace how its requests handle errors, especially /api/v1/instances.get. Verify the behavior with the listed API responses and browser Network panel. Done means successful sections still render while the Instance section shows an appropriate localized error instead of the whole page displaying "Error loading pages".