The version tag is added even when it pushes an event past MAX_TAGS #16

MAX_TAGS is documented in trace_client/trace_client.py as "The most tags one event carries: the trace server's limit", and _with_install refuses to add install once an event has MAX_TAGS tags. _with_version has no such check: it adds version whenever the event's own tags lack one, whatever their count.

So client.report("x", tags={"t%d" % i: "v" for i in range(32)}) sends 33 tags — one past the limit the client itself names — and, if the server enforces that limit, the whole event is rejected (logged at DEBUG and dropped) even though the caller's own 32 tags were within it.

Options to decide between:

• Leave it: an event that already uses every tag slot is the caller's problem; document that version is always added.
• Drop the lowest-priority caller tag, or skip version, to stay within MAX_TAGS (the README currently promises tags "always holds at least version", so skipping it changes a stated promise).

Either way the behavior is Java-visible: trace-client-java's handling of its version tag at the cap should be checked and the two kept in lockstep, so this is not being changed from the Python side alone.

Found during triage; not changed in the test-expansion PR opened the same cycle, which deliberately does not characterize this path.

This issue was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).

drafted by Claude on behalf of Daniel Stephenson