Wire FoilholeDetail micrograph card to the new micrograph_image endpoint (ADR 0021)

## Context

The micrograph (exposure) leaf of the **Atlas → Grid Square → Foil Hole → Micrograph** hierarchy is about to become servable: `smartem-decisions` adds `GET /micrographs/{uuid}/micrograph_image` (ADR 0021 — devtools PR #232; backend PRs `smartem-decisions#312` serving / `#311` ingestion). It returns the motion-corrected preview — a JPEG snapshot as-is, or the motion-corrected MRC rendered to PNG, else 404.

On the frontend, `MicrographCard` still renders a grey **placeholder** box, so the most scientifically meaningful image in the hierarchy is the only one not shown. This is the frontend follow-on named in ADR 0021's consequences and the leaf half of the image-serving thread (#111).

## Scope

Wire the micrograph card to the new endpoint, reusing the existing authenticated-blob image pattern.

- **File:** `apps/smartem/src/components/foilhole/FoilholeDetail.tsx` — `MicrographCard` (~L203), replacing the placeholder image block (~L219).
- **Pattern to follow (already in the repo):** the generated blob query hook → `useBlobObjectUrl` → ``, as done for the atlas / grid-square images in `apps/smartem/src/routes/…squares.gallery.tsx` and `…atlas.tsx` (`useBlobObjectUrl` at `apps/smartem/src/hooks/useBlobObjectUrl.ts`). The image routes are auth-gated, so a plain `` 401s — the blob→objectURL hook is required (see #116).
- After the backend endpoint ships in the published spec, regenerate the client with `npm run api:update` (fetches `smartem-decisions` `docs/api/openapi.json` + runs orval). That produces the typed blob hook, named per convention roughly `useGetMicrographImageMicrographsMicrographUuidMicrographImageGet`.

## Behaviour

- **Graceful 404 / loading:** the endpoint returns 404 for every micrograph until the cryoem-services adapter (`smartem-decisions#310`) supplies the paths. Keep the current placeholder/checkered fallback on 404 and while loading — do **not** surface an error state.
- **Avoid a fetch storm:** one image request per card multiplies the per-page fan-out that already pressures the backend (see #111 and the atlas-overview OOM). Fetch lazily — only when a card is in view or expanded — rather than eagerly for every micrograph in the foil hole.
- The endpoint accepts an optional `x,y,w,h` crop (parity with `atlas_image`); not needed for the card thumbnail, but available if a zoomed micrograph view is added later.

## Dependencies / notes

- **Blocked on** `smartem-decisions#312` (+ `#311`) merging and appearing in the backend's published `openapi.json`. Until then there is no generated hook to call.
- `MicrographCard` currently consumes the `MockMicrograph` type; the wiring needs the real micrograph `uuid` threaded through `FoilholeDetail`. Confirm the card receives real micrograph data (real uuids) — if it is still mock-backed here, that rethread is part of this work.
- No backend or ADR change is required by this issue; it is purely the frontend card wiring.

Start with MicrographCard in apps/smartem/src/components/foilhole/FoilholeDetail.tsx, then compare the authenticated image flows in the squares.gallery.tsx and atlas.tsx routes and useBlobObjectUrl.ts. After the backend spec is available, run npm run api:update and verify the generated micrograph image hook and real micrograph UUID data. Done means lazy-loaded cards show the endpoint image, while loading or 404 responses retain the existing placeholder without an error state.

Written by the indexing model from the issue text.