Analyse page-load performance and add lightweight instrumentation

@codex

Analyse ClimateExplorer performance and add lightweight instrumentation to identify the main contributors to page load time and perceived slowness.

Create a new branch from development.
Do not push directly to main.
Open a PR when complete.

Goals:

• Measure real page load and interaction performance across Blazor Server and WASM.
• Identify expensive API calls, data loading paths, rendering work, and lifecycle methods.
• Compare initial load, first usable render, and fully-loaded state.
• Keep the implementation lightweight and easy to remove or expand later.

Scope:

• Add client-side performance marks/measures using the browser Performance API via JS interop.
• Add C# ILogger timing around important component lifecycle methods, services, API calls, and data-loading paths.
• Instrument major pages/components rather than only the deferred location dictionary load.
• Include context such as page/component name, location id/name where available, render mode if available, cached vs uncached data, API endpoint, elapsed milliseconds, and record counts/data sizes where practical.
• Avoid introducing a heavyweight telemetry provider for now.
• Avoid changing app behaviour unless a very obvious performance bug is found.

Investigate:

• Initial app/page load
• Location page/dashboard load
• DataSetDefinitions load
• Regional/global pages if relevant
• Chart/data preparation
• Location dictionary loading
• Recent observations loading
• Climate record API calls
• Any duplicated or unexpectedly early API calls
• Any expensive work happening in OnInitialized/OnParametersSet/OnAfterRender
• Any render loops or unnecessary StateHasChanged calls

Deliverables:

• Lightweight performance instrumentation
• A short performance findings document or PR summary
• List of the slowest or most suspicious code paths found
• Any obvious low-risk fixes, only if they are clearly safe
• Notes on how to compare before/after timings locally

Please run existing tests/build checks and include results in the PR summary.

Start by reviewing the Blazor Server and WASM page-load paths, component lifecycle methods, services, API calls, and existing tests/build checks. Use the browser Performance API through JS interop and C# ILogger timing to compare initial, usable, and fully loaded states; done means lightweight instrumentation, findings, comparison notes, and test/build results in the PR summary.