fix(portal): degrade blocks instead of blocking the render when data-fair is down

[BatLeDev]

When data-fair answers slowly or not at all, a portal goes dark: its ssr calls toward data-fair had no timeout — undici defaults to 300s — so one hanging call held a whole page render hostage, including pages that need no dataset. This restores the graceful degradation the v1 portals have, without giving up ssr rendering of the datasets, which is the whole point of indexing them.

• data-fair ssr calls go through their own undici dispatcher, capped at 5s of inactivity, with a connection pool separate from the calls to our own services
• every block that takes its content from data-fair (metrics, topics, datasets and applications lists and catalogs, dataset card, application) renders a warning instead of looking empty — a catalog used to announce "0 jeu de données" and the metrics to show zeros
• such a page is served as a 503 with Retry-After: 60, so a crawler comes back later rather than indexing a portal emptied of its datasets; the dataset and application pages get the same treatment, their 500 fallback becomes a 503
• useCatalog exposes an unavailable boolean next to its existing fetch error
• chore: dev/worktree.sh runs npx patch-package, which nothing did on install — a fresh worktree ran on an unpatched vuetify and failed the tab slider e2e test, with no relation to the branch under work

Why: measured on opendata.edf.fr while data-fair was struggling — the portal served nothing, where a v1 portal (data.ademe.fr) still served its pages. The difference is not ssr, both render server side, but the absence of any timeout and a single connection pool shared by every service call.

Heads-up:

• the 5s cutoff itself is not covered by a test: undici's timers are too coarse to trip on a local data-fair that answers in ~30ms. What is verified end to end is everything after the failure — degraded block, 503, Retry-After — by hand against a data-fair returning 500, and by an e2e test for the client side navigation.
• answering 503 because blocks failed is deliberate, and worth challenging: it trades a degraded page for a crawler that comes back. A status already set by page-error (404, 403) still wins.
• the news, events and reuses catalogs share useCatalog but keep their current behavior, silently empty: they query the portal API, not data-fair. One line each if we want them covered.
• the two ui files are type plumbing for the shared components' auto-imports, no behavior change in the page editor.