Add feature vectors to existing detections, and reprocess detections without re-detecting

[mihow]

Summary

Once #1462 stores a feature vector for each detection, most existing detections will still have none, because vectors only arrive when images are processed again. This ticket covers a job that fills in vectors for detections that already exist without detecting them again, and the processing-service contract it needs.

The same contract also covers a long-standing need: re-classifying existing detections, for example with a new classifier, without running the detector again. Both come down to Antenna sending the detections it already has to a processing service, and the service returning results for those boxes.

What exists today

• Antenna already sends existing detections in the synchronous (push) pipeline request. This came in Support re-processing detections and skipping localizer #815, closing Support for reprocessing detections and skipping detector #706, "Support for reprocessing detections and skipping detector".
• The processing service does not use them yet: Reprocess existing detections if they are present in the pipeline request ami-data-companion#85.
• The queued (pull) path's task message carries no detections at all, so queued jobs cannot reprocess boxes.
• Per-request pipeline settings, in both push and pull mode, are Send the pipeline configuration to processing services in both push and pull mode, per project and per job #1422. feat(ml): propagate pipeline config through NATS pull-mode tasks #1279 sends pipeline settings through pull-mode tasks.
• Emit an embedding for every detection ami-data-companion#170 and Bump react-admin from 4.8.4 to 4.11.4 in /frontend #175 make the service emit a vector for every detection.

Proposed scope

1. Contract. Detections travel in both the push request and the pull task message, with a way to ask for vectors only (no classification) or for classification of the given boxes only. Settings travel per request (Send the pipeline configuration to processing services in both push and pull mode, per project and per job #1422, feat(ml): propagate pipeline config through NATS pull-mode tasks #1279).
2. Processing service. The service honours detections in both modes (ami-data-companion#85) and skips its detector when boxes are given.
3. Antenna job type. "Add feature vectors" runs on a capture set, a session or a project, optionally only for detections that have no vector for the chosen model. It reports how many vectors were stored, how many were unchanged, and how many boxes could not be matched. The same job shape can later run "reprocess detections" with a classifier.
4. Testing without the ADC. The minimal processing service in the main Docker Compose stack (Add processing service v2 template to main docker compose stack #1252) implements the contract, so the whole path, push and pull, can be tested end to end in Antenna's own CI.

Starting point

An earlier version of #1462 contained a first implementation of the feature-only path: queued tasks carrying detections, saving vectors for existing detections, and per-job counts. It was taken out to keep #1462 focused on storage, and is kept on a local backup branch to seed this work.

Related

#1462 (vector storage), #1417, #1457, #1422, #1279, #815, #706, #1252, RolnickLab/ami-data-companion#85, #170, #175.