fix(workflows): preserve image dimensions on empty VLM detections

[davidnichols-ops]

Summary

The numpy serialiser returned {"width": null, "height": null} for empty VLM-as-detector results, while the tensor-native path returned real image dimensions. This PR fixes the discrepancy.

Root Cause

sv.Detections.data is per-row. For zero-row detections, the serialiser's per-row loop never executes, so IMAGE_DIMENSIONS_KEY stored in data is never read. The tensor-native path avoids this because it stores image dimensions in image_metadata (a dict on the Detections object, not per-row).

What Changed

1. New helper empty_detections_with_image_metadata() in utils.py — creates a zero-row sv.Detections with metadata={IMAGE_DIMENSIONS_KEY: [h, w]}. sv.Detections.metadata is a free-form dict that survives zero rows (unlike data, which is per-row).

2. Serialiser fallback in serialise_sv_detections() — after the per-row loop, if image_dimensions is still None, read from detections.metadata.get(IMAGE_DIMENSIONS_KEY).

3. All 7 VLM-as-detector parsers (anthropic, gemini, muse, openai, qwen, spacexai, v2/llm) — replaced return sv.Detections.empty() with return empty_detections_with_image_metadata(h, w).

Before

>>> serialise_sv_detections(parse_gemini_object_detection_response(image, [], classes, inf))
{'image': {'width': None, 'height': None}, 'predictions': []}

After

>>> serialise_sv_detections(parse_gemini_object_detection_response(image, [], classes, inf))
{'image': {'width': 640, 'height': 480}, 'predictions': []}

Testing

• 1905 tests pass (0 failures)
• New regression tests in 7 test files verify that each parser's empty output carries image dimensions in metadata and serialises to real width/height
• 2 dedicated serialiser tests verify the metadata fallback path and the backward-compatible None path

Notes

• sv.Detections.metadata is an existing supervision field that was unused in this codebase
• sv.Detections.merge() filters empty detections before merging, so metadata on empty detections does not interfere with merge operations
• The int() call in the serialiser replaces .item() to handle both numpy arrays and plain Python lists from metadata

[davidnichols-ops]

Because this comes from a fork, could someone approve the Actions run before merging? I'm trying to document the actual external-contributor path rather than infer it from the workflow YAML.