opentelemetry-propagator-jaeger: enforce baggage limits on extract (#5556)

* Enforce baggage limits on the Jaeger extract path

The Jaeger propagator extracts every uberctx- header into baggage with
no bound: _extract_baggage walks all carrier keys and sets each one, so
an inbound carrier decides how much baggage enters the context.

The Jaeger format defines no limits, so this borrows the W3C Baggage
spec limits (180 entries, 4096 bytes per entry, 8192 bytes total,
byte-denominated), dropping members once a limit is reached and keeping
the earlier ones. opentelemetry-java caps its Jaeger propagator the
same way for the same reason (CVE-2026-45292).

Adds four extract tests: entry count, per-entry bytes, per-entry bytes
measured in bytes rather than characters, and the total-bytes cap. Each
fails without the change.

Assisted-By: Claude Fable 5

* Add changelog fragment for #5556

Assisted-By: Claude Fable 5

* Bound the extract work and count the separator bytes

Two points from review. The entry limit bounded the entries kept, not the
candidates inspected, so a carrier full of oversized uberctx- headers could force
unbounded decoding and byte accounting; the limit now bounds the candidates via
itertools.islice, which also makes the accepted-entry counter redundant since kept
is at most inspected. opentelemetry-java bounds its jaeger baggage parse the same
way, in MAX_BAGGAGE_HEADER_TOKENS.

The per-entry accounting also omitted the "=" and "," a baggage header carries, so
each entry now counts two more bytes. That makes the numbers slightly stricter
than opentelemetry-java, which counts key and value only.

Assisted-By: Claude Fable 5

* Keep the lint gate clean for the added tests

The tests added here take the class past pylint's max-public-methods of 20, which
fails `lint-opentelemetry-propagator-jaeger`. Disable that check on the class, the
same way `propagator/opentelemetry-propagator-b3/tests/test_b3_format.py` does, and
rename the loop variables the new tests introduced so `invalid-name` stays quiet
without a second suppression.

Assisted-By: Claude Fable 5

* fix: address review comments on the jaeger baggage limits

Fix the extract-side byte accounting: entry_bytes charged both the "="
and the "," on every entry, but the "," only ever appears between
entries. Charge "=" per entry and "," once per already-accepted entry
against the running total instead, in a shared _limit_baggage_bytes
helper.

Cap inject the same way extract is capped, so an in-process baggage map
built without going through extract cannot produce an unbounded number
or volume of uberctx- headers either. Both paths now build a bounded
list of candidate pairs, then filter it through the same byte budget.

Update the changelog fragment to cover both directions.