web: refactor progress backdrop query tracking

[dgdavid]

Initially, internal ProgressBackdrop component at core/Page, relied on a global event system to detect when proposal-related queries finished refetching in order to consider an ongoing progress in the given scope was finished (check #2947). While this worked on the storage page, it failed on other pages becuae the central useProposalChanges hook is invalidating an storage-related query, which is not refetched until navigating to a storage-related page. As a result, the progress backdrop could remain stuck on unrelated storage pages.

This commit refactors the tracking mechanism to make it more flexible and page-aware:

• Start exporting query keys as constants (COMMON_PROPOSAL_KEYS, STORAGE_MODEL_KEY, etc.) from their respective modules

• Add the additionalProgressKeys prop to Page, allowing pages to specify extra query keys to track alongside the common proposal-related queries

• Use useTrackQueriesRefetch directly into ProgressBackdrop, dropping the need for a custom global event system

• Remove the proposal:updated event infrastructure (onProposalUpdated, dispatchProposalUpdated), which is no longer required

With this change, pages can explicitly declare which additional queries must complete refetching before the UI is unblocked. For example, the storage ProposalPage now waits for the storageModel query in addition to the common proposal queries.

While requiring pages to be explicit about the queries they depend on is not ideal, this preserves common proposal tracking as the default while preventing the UI from remaining blocked due to unrelated query invalidations.

[imobachgs]

np: Is a "Key" or a "Query"? I know it is a "query key", but it refers to a query.

[dgdavid]

You're right... I tried to keep the prop shorter but I've another idea in mind for next iteration that might help. Stay tuned 😉