[BUG] `MlflowRouter` blanks the entire UI while a single query is loading

[!WARNING] Before submitting a PR, please make sure that:

• A maintainer has triaged this issue and applied the ready label
• This issue has no assignee
• No duplicate PR exists

PRs not meeting these requirements may be automatically closed.

MLflow version

master (3.16.1.dev0)

Describe the problem

MlflowRouter refuses to build the router at all while a single query is still loading:

// mlflow/server/js/src/MlflowRouter.tsx
const { workspacesEnabled, loading: featuresLoading } = useWorkspacesEnabled();

const hashRouter = useMemo(
  () =>
    // Don't create router while still loading features
    featuresLoading ? null : createHashRouter([...]),
  [routes, workspacesEnabled, featuresLoading],
);

// Show loading skeleton while determining if workspaces are enabled
if (featuresLoading || !hashRouter) {
  return <LegacySkeleton />;
}

featuresLoading comes from useWorkspacesEnabled(), i.e. the serverInfo React Query. Any condition that keeps that one query from settling takes down the entire application shell, with no error, no route, and no way for the user to reach any page.

This is not hypothetical. #25933 is exactly that failure: React Query paused the serverInfo query because navigator.onLine was false, the query never settled, and the whole UI sat on a skeleton indefinitely. The immediate cause is being fixed at the query layer, but the structural exposure remains — a slow server, a hung request, or any future query wired into this gate reproduces it.

Suggested fix

Do not hard-gate router creation on this flag. Render the router and fall back to workspacesEnabled: false while the value is unknown, which is exactly what DEFAULT_RESPONSE already encodes for servers that do not report workspace support:

const DEFAULT_RESPONSE: ServerInfoResponse = { store_type: '', workspaces_enabled: false, ... };

Every other consumer of this query already defaults independently (data?.workspaces_enabled ?? false, ?? defaultValue), so the router would be following an established pattern rather than inventing one. Worth regression coverage for the fallback path.

Note on ownership and scope

@Rudra-G-23 offered in #25933 to take this one, and I am filing it only so the work has a target to be triaged against — this is a report, not a claim.

It is filed separately from #25933 on purpose. That issue is already linked by a PR closing it, and auto-close-pr.js closes any PR that links an issue "already claimed by an earlier open PR", so two PRs closing the same issue would cost one of them.

What component(s) does this bug affect?

• area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev server