Refactor INPUT_CHANNEL into a scalable channel registry

[pecomyint]

Context

DashPVA has two pipeline models that use different channel persistence:

Interactive Pipeline (Area Detector → pyFAI → Phase Fitter):

• Channels propagate via CLI --pv-address args between subprocess launches
• Root channel persisted in settings.py as INPUT_CHANNEL

Managed Pipeline (Workflow → HPC RSM → HKL 3D):

• Channels configured per-consumer in the Workflow UI, stored in the database under APP_DATA > workflow
• HKL 3D viewer channel persisted separately as INPUT_CHANNEL_HKL3D

Currently, each viewer that needs its own persisted channel requires a new global variable in settings.py, a new getter function, a new saver function, and updates to reload(). This doesn't scale well as more analysis chains are added.

Proposal

Replace flat INPUT_CHANNEL / INPUT_CHANNEL_HKL3D globals with a channel registry dict:

# settings.py
INPUT_CHANNELS: Dict[str, Optional[str]] = {}

def get_input_channel(viewer_key: str, fallback: str = "pvapy:image") -> str:
    return INPUT_CHANNELS.get(viewer_key) or fallback

def save_input_channel(viewer_key: str, channel: str) -> bool:
    INPUT_CHANNELS[viewer_key] = channel
    # persist to config source under 'INPUT_CHANNELS' dict

Each viewer registers a key (e.g., 'detector', 'hkl3d', 'future_chain'). Adding a new chain is just picking a key — no new globals, no new functions.

Files affected

• src/dashpva/settings.py — Replace globals with dict, refactor get/save functions
• src/dashpva/viewer/area_det_viewer.py — Use get_input_channel('detector')
• src/dashpva/viewer/hkl3d/hkl_3d_viewer.py — Use get_input_channel('hkl3d')
• src/dashpva/viewer/scan_view.py — Use get_input_channel('scan')
• src/dashpva/viewer/vit_viewer.py — Use get_input_channel('vit')
• src/dashpva/utils/config/source.py — Handle dict serialization in ConfigSource
• tests/unit/test_settings.py — Update INPUT_CHANNEL tests

Design notes

• Backward compatible: existing TOML configs with flat INPUT_CHANNEL key should be migrated on reload()
• Workflow channels (managed pipeline) stay in the database — this refactor only covers viewer-side persistence
• The choice of pipeline model (interactive vs managed) depends on whether the analysis is user-driven or needs frame-rate throughput — see README Architecture section