Add segmentation, corrector backends, and advanced acquisition workflows

[AustinHouston]

Summary

This PR adds a standalone GPU segmentation workflow, splits the aberration corrector into concrete CEOS and digital-twin backends, and expands the acquisition and simulation examples around those services.

Review focus

1. Segmentation service

• Adds a SAM2-backed Tango segmentation device with CUDA selection and startup validation.
• Adds startup_scripts/run_segmentation.py and configs/Segmentation.yaml; the launcher starts only the segmentation server against an existing Tango/DATA/Tiled stack.
• Reads source acquisitions by Tiled key, writes the label array directly to Tiled, and returns a new segmentation data key with source/model/area-statistics metadata.
• Adds segmentation dependency groups, documentation, a notebook, and focused tests.

2. Corrector backend split

• Keeps a backend-neutral CORRECTOR Tango API and separates concrete implementations into CEOSCorrector and DigitalTwinCorrector.
• Updates hardware configs to select the CEOS backend explicitly.
• Adds corrector coverage and exercises the digital-twin path in the accompanying simulation notebooks.

3. 4D-STEM acquisition and data handling

• Adds AutoScript advanced camera acquisition support for 4D-STEM data.
• Adds DATA-side MRC-to-HDF5 conversion and atomic registration with Tiled.
• Includes the AutoScript MRC/HDF5 debug notebook and focused acquisition/data tests.

4. Polycrystalline-gold digital twin

• Adds a polycrystalline-gold microscope digital twin, configuration, tests, and a rerun example notebook.
• The notebook captures the current end-to-end acquisition/corrector workflow and updated outputs.

Additional cleanup

• Removes the unsupported electron_counting camera setting from the Tango device, shared microscope contract, digital twins, tests, and notebooks.
• Removes the old 06_Digital_Twin_Tilt.ipynb intentionally; 06_Segmentation.ipynb now occupies that numbered example slot.
• Leaves the general run_servers.py flow unchanged; segmentation uses its standalone runner.

Validation

• uv run --extra segment --extra diffraction ruff check ...
• uv run --extra segment --extra diffraction pytest tests/test_segment.py tests/test_run_segmentation.py tests/test_data_device.py tests/test_corrector.py tests/test_polycrystalline_gold_digital_twin.py tests/test_auto_script_microscope.py tests/test_run_servers.py tests/test_digital_twin_diffraction.py tests/test_digital_twin_tilt.py tests/test_CAMERA.py -q — 82 passed
• Standalone runner checks: 11 passed
• Edited notebook JSON validated with jq empty

[utkarshp1161]

I think we should call this SamSEGMENTATION. As we will have simple unets to segment as well. I think a base SEGMENT class might be a good idea in long run.

[utkarshp1161]

I wonder why is it under mcp folder? Shall we create a post-processing folder?

[DomPTech]

I was thinking maybe rename the folder to "intelligence" or something like that? Since llm.py also lives under that folder aswell

[utkarshp1161]

Again, I think this should be named - SAMsegmentation.yaml

[utkarshp1161]

This is great!

[utkarshp1161]

I think this issue is relevant here - #175