[ENHANCEMENT] Keep usage metrics state across renders

[Gladorme]

Description

Split out of #319 to ease review (independent from the other split PRs, based on main).

Fix and simplify usage metrics collection.

• UsageMetricsProvider previously rebuilt its accumulator object on every render, so pending query state, error count and the "already submitted" flag could be lost. The accumulator now lives in a ref owned by the provider, and metrics are submitted only once per dashboard (the provider is keyed by project/dashboard, so switching dashboard starts a fresh measurement).
• DataQueriesProvider records query states in an effect (after commit) instead of during render, and registers the whole batch as pending before completing cached queries.
• useUsageMetrics() returns a stable markQuery.
• markQuery returns early once metrics are submitted, so later query updates (refreshes, time range changes) cost nothing.
• A failed submission request now logs a warning instead of producing an unhandled promise rejection.
• Added UsageMetricsProvider tests, plus DataQueriesProvider.usage-metrics.test.tsx covering batch registration with a cached query and no recording from renders that are never committed.

⚠️ Note for reviewers: the value exposed through the exported UsageMetricsContext / useUsageMetricsContext() now contains project, dashboard, apiPrefix and markQuery; the internal accumulator fields (startRenderTime, renderDurationMs, renderErrorCount, pendingQueries, fetchFn) were removed. I'm not aware of consumers reading those fields directly, but tell me if you'd prefer to flag this as [BREAKINGCHANGE].

Validation on this branch: npm run lint, npm run format:check, npm run type-check and npm run test all pass.

Screenshots

No visual change.

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.