fix: YOLO format requires the box CENTER, not the corner

[duane-edgington]

Addresses Issue
#77

This PR fixes a bug in mbari_aidata/generators/coco_voc.py.

The fix changes the affected logic from mbari_aidata/generators/coco_voc.py, in download()'s direct-to-YOLO export path, writes
TATOR's native top-left (x, y) directly into the fields YOLO format expects to be the box
center — with no +width/2, +height/2 conversion. Every YOLO .txt label ever produced by
this code path has its box shifted up-and-left by exactly half the box's own width and height.

This does not affect VOC or COCO exports elsewhere in the same file — only the unconditional
"Creating YOLO files" block that runs on every download() call regardless of --voc/--coco
flags to

correct placement of box.

Downstream, a shifted box [x1_s, y1_s, x2_s, y2_s] (reconstructed by any standard YOLO-format
reader) satisfies:

center(shifted_box) == top_left_corner(true_box)

exactly, and the shift magnitude equals exactly half the box's own width and height — not a
fixed pixel offset, but proportional to each box's own size. Verified on real exported data from
a downstream project (98-image benchmark, single class): a box with stored (buggy) pixel
coordinates [3754.8, 2364.0, 4046.1, 2674.0] reconstructs correctly to [3900.3, 2519.1, 4191.7, 2828.9] once corrected — center of the shifted box (3900.5, 2519.0) matches the true
box's top-left corner to rounding, and the offset (145.5px, 155.1px) matches exactly
half the box's width/height (291.3/2, 309.8/2).

Testing:

• Reproduced the original problem.
• Applied the change.
• Verified that the corrected code produces the expected result.

No automated regression test is included because no applicable test program
or fixture is currently available. See the Issue text for verification suggestion.