Add model specific explainer compatibility and inherited compatibility resolution

[Irozuku]

Summary

Explainers were associated only to tasks, wrongly assuming every explainer is model agnostic. This PR establishes the compatibility semantics: an explainer declaring a task in COMPATIBLE_COMPONENTS is model agnostic for that task, while a model declaring an explainer's name in its own COMPATIBLE_COMPONENTS unlocks that model specific explainer. The registry merges COMPATIBLE_COMPONENTS across the class hierarchy so declarations on shared bases (e.g. SklearnLikeClassifier) propagate to every subclass, and the frontend offers the union of task related and model related explainers for the run's model.

---

Type of Change

• Backend change
• Frontend change
• CI / Workflow change
• Build / Packaging change
• Bug fix
• Documentation

---

Changes (by file)

• DashAI/back/dependencies/registry/component_registry.py: _collect_compatible_components() unions each class's own COMPATIBLE_COMPONENTS along the MRO (deduplicated), used by both register_component and unregister_component, so mixins and base classes compose instead of the first declaration shadowing the rest.
• DashAI/front/src/components/explainers/SetNameAndExplainerStep.jsx: fetches task related plus model related explainers in parallel and deduplicates by name.
• DashAI/front/src/components/models/RunResults.jsx, explainers/{InlineExplainerCreator,NewGlobalExplainerModal,NewLocalExplainerModal}.jsx: thread modelName (run.model_name) into the creation flow.
• tests/back/registries/test_registry.py: MRO merge coverage (mixin + base + subclass redeclaration deduplicates; unregister removes inherited edges symmetrically).

---

Testing

• Audited all registered components: the merge produces identical relationship edges for every existing component (behavior only changes when hierarchies genuinely combine lists).
• Manual: tabular run offers the same explainers as before; with a model that declares an explainer, that explainer appears only for its runs.

---

Notes

• No backend validation on POST endpoints by design: enforcement is a frontend filter (the backend graph already had the capability).
• The union is additive only; there is no per subclass opt out of inherited explainer declarations yet.