web: disable TanStack Query structural sharing

[dgdavid]

TL;DR

Fixes ProgressBackdrop infinite blocking by disabling structural sharing in QueryClient default options.

Problem

Recently introduced ProgressBackdrop component uses a custom useTrackQueriesRefetch hook that subscribes to the QueryCache to detect when specific queries have been refetched. This allows the UI to unblock in the right moment when a progress finishes and the data for render the resulting interface is really ready.

However, TanStack Query's structural sharing optimization prevents QueryCache events from being emitted when refetched data is identical to the previous data. When structural sharing is enabled (the default), the library reuses the previous data reference for deeply equal results, which means no updated event is fired. This makes it impossible for our subscription to detect that a refetch occurred, breaking the progress tracking functionality.

This issue was discovered on the storage proposal page. While validation issues prevent a storage proposal, the API will return an identical response (a proposal object without storage data) on each refetch (if nothing else has changed in other areas). Since the response remains unchanged and no updated event is fired, ProgressBackdrop never detects the refetch completion and blocks the UI indefinitely if the user was not able to fix the issue in the first attempt to produce a different proposal. The same pattern is expected in other areas where the API response is identical to previous after a ProgressBackdrop block.

Solution

Disable structural sharing globally for all queries by setting structuralSharing: false globally in the QueryClient default options. This ensures that QueryCache subscriptions always receive updated events when queries refetch, regardless of whether the data changed.

The performance impact is expected to be minimal:

• Identical data responses should be not that common
• React reconciliation is efficient and only applies DOM updates when rendered output differs. Additionally, components should use useMemo/useCallback to prevent heavy computations from re-executing when data hasn't changed

Alternatives Considered

Several alternatives were evaluated but rejected as unnecessarily complex:

• Adding artificial timestamps to JSON responses: it achieves nearly the same result but breaks types and pollutes the data model
• Reverting to query observer pattern: more complex and more subscriptions with no clear benefit
• Manual notifyOnChangeProps configuration: requires per-query or global configuration overhead, defeating the more convenient "tracked" default.
• Separate tracker queries: a no go because increases not only the complexity but the maintenance.

Additional changes

Minor issues in tests has been fixed as part of this PR.