No installed format writes a classification tag, so the multi-tag export rule has nothing to attach to

[JArmandoAnaya]

Decided 2026-08-15:

Classification exports emit one entry per (image, tag) pair — an image with N tags appears N
times, once per tag.

Found while implementing it: there is nowhere to put the rule. Every installed exporter has an
explicit branch that drops a classification tag.

exporter	supported_geometries	what it does with a tag
coco	{BBOX, POLYGON}	_annotation() returns None, row skipped
yolo	{BBOX}, degraded {POLYGON}	_as_box() returns None, _rows() continues
voc	{BBOX}, degraded {POLYGON}	_as_box(): "a classification tag: no location, and VOC's <object> is a location"
the five lane formats	{POLYLINE}	not written
dummy	every geometry	declares it, writes nothing at all

The only tag-supporting exporter in the repo is a fake inside tests/cli/test_export_commands.py.
Three tests pin today's behaviour: test_a_classification_tag_produces_no_object_at_all (voc),
…_produces_no_row_at_all (yolo), …_makes_the_release_need_consent (coco).

So the rule cannot be violated by code that does not exist. It is really the specification for a
format nobody has written: an image-classification layout whose content is tags — a folder tree
per class, or a labels.csv.

What it takes

1. A module under src/visionset/formats/, supported_geometries including
   GeometryType.CLASSIFICATION_TAG, registered in [project.entry-points."visionset.formats"].
2. One row per (image, tag). This already agrees with the pre-export report, which counts
   annotations rather than images (ReleaseService._compatibility, keyed
   (label_class, geometry)) — a per-image emitter is the one that would disagree with it.
3. tests/formats/test_report_agreement.py is a hard gate: a new exporter either lands a counter
   there or is declared as one that writes nothing, and
   test_every_installed_exporter_is_accounted_for fails until somebody chooses. Its counters read
   rows back off disk.
4. The report has no per-image line today, so "how many images were duplicated by multiple tags"
   needs a home if it is wanted.

Worth deciding at pickup: a new format, or a second task file inside coco. The second changes
bytes for existing consumers and breaks the three pinning tests, so it is the more expensive of the
two despite looking smaller.

[JArmandoAnaya]

A dispatch reached this issue reading it as a silent-drop defect — that a classification tag is
included in a release and then dropped by every exporter without the export ever saying so, and
that the remedy is to bring tags into the lossy-detection mechanism. Verified against the code
before writing anything, and that reading is wrong, so recording it here rather than leaving the
next person to re-derive it.

The drop is already declared, refused, and enumerated. _compatibility in
src/visionset/kernel/services/release_service.py keys its report by (label_class, geometry) and
reads each one's status off the format's two declared geometry sets, so a classification tag under
a format whose supported_geometries omits it is counted as excluded like any other unwritable
shape. ReleaseService.require_export_consent then refuses unless the caller passed
allow_lossy, and its docstring already carries the rule the dispatch proposed adding: consent is
required if either half says so, because a format declaring itself lossless still cannot silently
drop a geometry it never claimed to write.

Three tests pin exactly that behaviour today. In tests/formats/test_coco.py,
test_a_classification_tag_makes_the_release_need_consent asserts the refusal, that the report
names the class, and that no output directory is created; the sibling
test_under_consent_the_tag_is_dropped_and_the_report_enumerates_it asserts the written report
carries compatible: false, the excluded count, and the class by name and status. test_yolo.py
and test_voc.py pin the corresponding no-row and no-object outcomes. A red-first test written
against the dispatch's premise would have been green at HEAD.

So nothing about consent or the drop report needs to change, and this issue is not a bug in it.
What the body above already says stands: the gap is that no installed format writes a tag at
all, which is why the one-entry-per-(image, tag) rule has nothing to attach to. That is a new
exporter, and the open choice it records — a new format module against a second task file inside
coco, where the second changes bytes for existing consumers and breaks the three tests above —
is worth settling before anyone starts.

One asymmetry noticed while verifying this, small and left alone: COCO is the only one of the three
with a test asserting the refusal. YOLO and VOC pin only that nothing is written. The behaviour
is identical because it comes from the same shared check, but a reader comparing the three files
would have no way to know that.