fix(sentry): read the logentry key the installed SDK fills, and mark its floor

[lesnik512]

Finishes the lower-bound work on #242. That issue's two named defects were fixed by #244 and #246; this clears what was left, and the suite now passes at the declared floors on every supported interpreter.

A real bug, not just a test problem

skip_sentry=True silently stopped suppressing events at the declared floor.

enrich_sentry_event_from_structlog_log reads the log text from event["logentry"]["formatted"]. That key is not universal — at sentry-sdk==2.1, which >=2.1 resolves to, a log event carries its text in logentry.message and has no formatted key at all:

sentry-sdk 2.1.0
logentry: {'message': '{"event": "hello", "skip_sentry": true}', 'params': []}

So the guard fell through, the payload was never parsed, and a log marked skip_sentry=True reached Sentry anyway. Nothing raised and nothing failed — the only symptom was the envelope count in one test, which is why it survived.

Now reads whichever key is present and writes the rewritten message back to that same key, so the enrichment lands where the SDK will render it.

sentry-sdk's floor is wrong on 3.13 and 3.14

Separately, sentry-sdk>=2.1 predates Python 3.13's FrameLocalsProxy:

TypeError: cannot pickle 'FrameLocalsProxy' object

raised while the SDK captures a request. Bisected against the suite, with sanity checks either side of each boundary:

interpreter	first sentry-sdk that passes
3.10 – 3.12	2.1 (unchanged)
3.13	2.11 (2.10.0 fails, 2.11.0 passes)
3.14	2.59 (2.58.0 fails, 2.59.0 passes)

Marked rather than raised, so 3.10–3.12 keep the lower floor.

The rest was test-side

The version guard in the instrument was already correct — SENTRY_LOGS_LEVEL_SUPPORTED inspects the signature, so production code works at 2.1. Four tests did not:

• two read integration._sentry_logs_handler, which does not exist below sentry-sdk 2.25
• one constructed LoggingIntegration(sentry_logs_level=...) directly, which raises there
• test_sentry_passes_sentry_logs_level_only_when_the_sdk_accepts_it forced the flag True and then read that same attribute — it could only ever run on an SDK that already had the parameter, which is the opposite of what it claims to check

That last one now records the kwargs the instrument passes instead of inspecting the constructed object, so it exercises both branches on any installed SDK. The handler assertion is guarded on the flag, and the user-supplied-integration test drops a kwarg that was incidental to what it asserts.

Tests

Written first, red before the change:

FAILED test_structlog_enrichment_reads_whichever_logentry_key_the_sdk_populates[message]
FAILED test_structlog_enrichment_writes_back_to_the_key_it_read[message]

Both parametrised over formatted and message, so they pass on the current SDK and fail on the floor — which is the shape that would have caught the original bug.

Verification

uv pip install --resolution lowest-direct with every extra, then the full suite:

interpreter	result
3.10	329 passed
3.11	329 passed
3.12	329 passed
3.13	329 passed
3.14	329 passed

just lint-ci clean. Normal resolution: 329 passed.

At the top of the range nothing changes — the lock still picks sentry-sdk 2.69.2 — so the floor edits are inert for anyone not installing at the lower bound.

Scope

Touches sentry_instrument.py, its tests, and the sentry-sdk floor only. No overlap with the Litestar work on #248.

This was the last of the 14 repos in the org-wide audit (modern-python/.github#107) still failing at its lower bound.