Stabilize django-plotly-dash apps by registering them at startup

[Aberdur]

PR Description

This PR fixes several intermittent failures in the platform Dash graphs.

Problems found

We were hitting two structural issues in the current django-plotly-dash integration:

1. Several Dash apps were being created during request handling instead of being registered once at Django startup.
2. Dash initial_arguments were configured to use cache storage, but the current deployment uses LocMemCache, which is process-local and not shared across workers.

Because of this, the page request and the embedded Dash iframe requests could be handled by different workers with different in-memory state. In practice, this caused inconsistent behavior such as:

• graphs loading empty even when data existed
• fallback messages like "No variants available for the selected sample"
• intermittent failures in embedded Dash routes
• inconsistent behavior after reinstall/redeploy

Changes applied

To solve this, the PR introduces the following changes:

• register the affected Dash apps once at startup through AppConfig.ready()
• stop creating Dash apps dynamically inside views and request-time helper functions
• pass per-view graph state explicitly through initial_arguments
• store Dash initial_arguments in the Django session instead of process-local cache
• keep the current Dash-based UI approach without replacing these graphs with plain Plotly/JS

Affected graphs

The stabilization was applied to:

• samplePerLabGraphic
• samplesReceivedOverTimeMap
• sampleVariantGraphic
• variationLineageOverTime
• needlePlotMutationByLineage

These changes make the graph state deterministic across requests and remove the worker-local state issues that were causing the inconsistent rendering.