Limits of Remix shouldRevalidate when skipping a loader's re-fetch after actions

Remix runs each route's loader on the server before rendering, and after an action it re-runs the loaders for all active routes by default so the UI reflects the mutation. The documented shouldRevalidate route export can return false to skip a loader during a navigation or after an action, using context about the current and next request.

The design question concerns a nested route where one loader performs an expensive query that rarely changes, while sibling loaders must stay fresh after every action. Because nested loaders run in parallel, that single slow loader still determines how long the batch takes. The goal is to suppress re-fetching only that loader without introducing stale UI, since the underlying data can also change independently of client actions.

• Under the default revalidation model, which loaders re-run after an action, and can shouldRevalidate opt out per route?
• Which parts of the provided arguments, such as the action result, params, and URLs, are reliable signals that a skip is safe?
• What stale-UI risks remain once a loader is skipped, and how are they typically bounded?