Add a diagnostic data-provider interface (isolate OMEGA specifics)

[joglekara]

What

Introduces a diagnostic data-provider interface — the primary goal @almilder called out in #105: isolate the OMEGA-specific diagnostic specifics behind a minimal interface so others can plug in their own diagnostic (e.g. NIF OTS) or supply preprocessed data without navigating the jax/AD model code.

"the most important goal of this decomposition is to isolate the diagnostic specifics (calibrations, data loading, k-smearing)... so that other users can add on their own diagnostic specifics (e.g. NIF OTS)... or supply preprocessed data instead of raw OMEGA files."

How

The pipeline already had the right seam: everything downstream of data loading (LossFunction, ThomsonScatteringDiagnostic, the optimization loops, postprocessing) consumes only a plain (all_data, sa, all_axes) tuple. All OMEGA-specificity sits upstream of it. This PR makes that seam an explicit, registerable contract.

• tsadar/data/__init__.py — register_data_provider(name) decorator + get_data_provider(config). A provider is any config -> (all_data, sa, all_axes) callable, selected by config["data"]["provider"] (default "omega").
• tsadar/data/omega.py — the OMEGA loader (moved out of fitter) as the reference provider, self-registered as "omega".
• fitter.fit resolves data via get_data_provider(config)(config); load_data_for_fitting stays as a thin back-compat shim.

Adding a new diagnostic now takes zero model-code changes:

from tsadar.data import register_data_provider

@register_data_provider("nif_ots")
def load_nif(config):
    ...                       # raw files OR preprocessed arrays — your choice
    return all_data, sa, all_axes

then config["data"]["provider"] = "nif_ots".

Behavior preservation

Configs without a provider key resolve to "omega" and follow the exact previous code path (incl. the multiplexed/rotated angular special case). Verified statically: registry resolves default→omega, empty-config→omega, unknown→clear KeyError; all intra-tsadar imports resolve; everything compiles. (Local jax is too old to run the suite — import smoke test + suite should be confirmed by a reviewer with a working env.)

Open question for @almilder

Supplying preprocessed data is now supported by registering a trivial provider that returns your in-memory (all_data, sa, all_axes). If you'd rather have a built-in "preprocessed" provider that reads from a file, what format do you want — .npz, xarray/netCDF, or just an in-memory dict passed programmatically? I left that out rather than guess the format.

Sequencing / not in scope

• Stacked on Refactor: break the 3 module couplings blocking a clean forward/inverse split #106 (the coupling-break PR). Review/merge that first; this branch retargets to main automatically once it lands.
• Still to come per Refactor: isolate a standalone forward kernel — 2 repos vs. 1 repo with 2 install paths? #105: postprocessor extraction (so users can swap visualization / plug into multi-diagnostic visualizers), folding k-smearing into the diagnostic layer (currently a dead inline flag in calc_vs_data), and the Option A install extras (note: tsadar/__init__.py eagerly imports runner→fitter→optax/mlflow, so a core-only install needs __init__ import-hygiene, not just pyproject changes).

Toward #105.

---

🤖 Generated with Claude Code