refactor(server): extract the duplicated image fetch/decode helper from the embeddings and rerank routes

## Summary

Extract one shared labeled image fetch/decode helper into `src/server/media.rs` and call it from both the embeddings and rerank routes, which today carry near-identical private copies.

## Background

The two routes each define their own private image-URL fetch/decode helper with the same call chain and the same three error messages, differing only in the label prefix used in the error text. They already share the underlying `ImageInput` type and both already import from `src/server/media.rs`, so a single helper there is the natural home.

## Proposed Solution

Add `pub(crate) async fn fetch_labeled_image(url, label, limits)` (name illustrative) to `src/server/media.rs` and replace both private helpers with calls to it. Pure extraction, no behavior change.

## Implementation Notes

- Duplicated helpers: `src/server/routes/embeddings.rs:134-167` (`fetch_images`) and `src/server/routes/rerank.rs:118-148` (`fetch_image`). Both signatures confirmed in source.
- Both walk `try_read_image_url_with_limits` then `decode_request_images_with_limits` then `pop()`, emitting the same messages ("unsupported image URL scheme" / "failed to read image: {err:#}" / "image decoded to nothing"), with `input[{index}]:` vs `{label}:` prefixes.
- Shared type already re-exported: `src/rerank/mod.rs:57` (`pub use crate::embeddings::ImageInput;`).
- Both files already import from `src/server/media.rs` (`embeddings.rs:38-41`, `rerank.rs:35-38`).
- Existing tests in `embeddings_tests.rs` / `rerank_tests.rs` cover the behavior.

## Acceptance Criteria

- [ ] One shared helper; both routes' error strings unchanged.
- [ ] Existing route tests pass unchanged.

---

## Original Suggestion

### Title: refactor(server): extract the duplicated image fetch/decode helper from the embeddings and rerank routes

The embeddings and rerank routes carry near-identical private image-URL fetch/decode helpers — same call chain, same three error messages — differing only in the label prefix.

## Evidence

- `src/server/routes/embeddings.rs:134-167` (`fetch_images`) vs `src/server/routes/rerank.rs:118-148` (`fetch_image`)
- Both walk `try_read_image_url_with_limits` → `decode_request_images_with_limits` → `pop()` and emit the same messages ("unsupported image URL scheme" / "failed to read image: {err:#}" / "image decoded to nothing"), with `input[{index}]:` vs `{label}:` prefixes
- They share the type already: `src/rerank/mod.rs:57` re-exports `crate::embeddings::ImageInput`
- Both files already import from `src/server/media.rs` (`embeddings.rs:38-41`, `rerank.rs:35-38`) — the natural home for a shared `pub(crate) async fn fetch_labeled_image(url, label, limits)`

## Suggested fix

Extract one labeled helper into `src/server/media.rs` and call it from both routes. Pure extraction; existing tests in `embeddings_tests.rs` / `rerank_tests.rs` cover the behavior.

## Acceptance criteria

- [ ] One shared helper; both routes' error strings unchanged
- [ ] Existing route tests pass unchanged

Start with the duplicated helpers at src/server/routes/embeddings.rs:134-167 and src/server/routes/rerank.rs:118-148, then inspect src/server/media.rs and the existing image helpers it imports. Run the embeddings and rerank route tests in embeddings_tests.rs and rerank_tests.rs. Done means both routes use one shared helper, error strings remain unchanged, and the existing tests pass.

Written by the indexing model from the issue text.