feat: cryoem-services adapter to supply motion-corrected image paths (ADR 0021, item 4)

Per **ADR 0021 — Micrograph Motion-Corrected Preview Image Ingestion and Serving** (smartem-devtools, Proposed), item 4. Coordination item, largely **outside `smartem-decisions`**.

## Context

ADR 0021 serves the micrograph leaf image from the motion-corrected artefacts cryoem-services produces, carried in through SmartEM's existing `POST /micrographs/{uuid}/motion_correction/completed` contract. The schema + contract side is tracked separately (ingestion prerequisite) and the serving endpoint is #308. This issue tracks the **producer** side: whatever calls `motion_correction/completed` must start supplying the two image paths.

## What's needed

cryoem-services motion correction (`services/motioncorr.py`) already generates both artefacts, and its images service (`services/images_plugins.py`, `mrc_to_jpeg`) already produces the downscaled JPEG (`{mrc}.jpeg`, ~1024 px). It already emits:
- `mc_path` — the motion-corrected 2D average `.mrc`
- `micrograph_snapshot_full_path` — the JPEG snapshot (sent to ISPyB)

The cryoem-services -> SmartEM adapter that calls `motion_correction/completed` (today effectively a simulator) must include these two paths in the request once the contract is extended. This is an additive change at the boundary, not new image production.

## Until then

The migration's two columns stay null and `GET /micrographs/{uuid}/micrograph_image` returns `404` — correct behaviour. This item does not block the schema/contract/endpoint work; it makes the endpoint return real images.

## Open questions
- Where does the adapter live / who owns it (cryoem-services side vs a SmartEM-side bridge)?
- Path visibility: are the cryoem-services output paths reachable from the SmartEM API pod's mount (ties into the existing image-path-resolution work)?

Start by locating the cryoem-services adapter that calls POST /micrographs/{uuid}/motion_correction/completed, then read services/motioncorr.py and services/images_plugins.py to confirm the existing artefact paths. Resolve where the adapter is owned and whether those paths are visible to the SmartEM API pod. Done means the request supplies mc_path and micrograph_snapshot_full_path after the contract is extended.

Written by the indexing model from the issue text.