fix(python): read consumer metadata without the consumer lock

[ethanlin01x]

Which issue does this PR address?

Relates to #3776 (Found while reviewing)

Rationale

The synchronous getters on the Python IggyConsumer took the consumer mutex with blocking_lock() while holding the GIL, and consume_messages holds that mutex for the whole consumption run. Reading an attribute during consumption hung the interpreter; reading one from a callback panicked inside the Tokio runtime. Neither is recoverable from Python.

consume = consumer.consume_messages(handle, shutdown_event)
print(consumer.name())   # never returns

What changed?

None of those getters need exclusive access.

name, stream and topic never change after construction, so the Python wrapper snapshots them. The partition id and offsets do change, but already live behind Arcs in the Rust SDK, which now hands them out as IggyConsumerState via IggyConsumer::state(). The wrapper keeps a clone and reads them as atomic loads, never taking the lock.

Additive on the Rust side. On the Python side stream() and topic() now return the identifier directly instead of a PyResult.

Local Execution

• Passed
• Pre-commit hooks ran

AI Usage

1. Which tools? Claude
2. Scope of usage? help implement and write PR description
3. How did you verify the generated code works correctly? Ran the Python test suite against a real server
4. Can you explain every line of the code if asked? Yes, all the changes are checked by the human.

[codecov]

Codecov Report

❌ Patch coverage is 79.22705% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.05%. Comparing base (5068a96) to head (fb031bd).

Files with missing lines	Patch %	Lines
core/sdk/src/clients/consumer.rs	76.10%	35 Missing and 3 partials ⚠️
foreign/python/src/consumer.rs	87.50%	5 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3888      +/-   ##
============================================
+ Coverage     84.04%   84.05%   +0.01%     
  Complexity     1358     1358              
============================================
  Files          1217     1217              
  Lines        171874   171901      +27     
  Branches     139631   139657      +26     
============================================
+ Hits         144449   144490      +41     
+ Misses        23496    23458      -38     
- Partials       3929     3953      +24     

Components	Coverage Δ
Rust Core	84.93% <76.10%> (+<0.01%)	⬆️
Java SDK	66.67% <ø> (ø)
C# SDK	75.05% <ø> (+0.07%)	⬆️
Python SDK	90.06% <89.58%> (-0.04%)	⬇️
PHP SDK	85.65% <ø> (ø)
Node SDK	95.90% <ø> (ø)
Go SDK	68.29% <ø> (ø)

Files with missing lines	Coverage Δ
foreign/python/src/client.rs	99.85% <100.00%> (+<0.01%)	⬆️
foreign/python/src/consumer.rs	81.34% <87.50%> (-0.90%)	⬇️
core/sdk/src/clients/consumer.rs	72.52% <76.10%> (-0.36%)	⬇️

... and 38 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ethanlin01x]

/request-review @hubcio

[ethanlin01x]

/ready

[hubcio]

fix is good, some polishing is needed tho.

three that don't fit on a diff line:

• foreign/python/src/consumer.rs:410-411: the lock_owned() guard is shadowed, not dropped, so it spans the whole consume() including the callback await. harmless today, but self.task_locals.lock().await.clone() drops it.
• foreign/python/src/consumer.rs:202: tokio::join! waits on the shutdown task even when consume already exited, and that task waits forever on Event.wait(). the new test is only safe because it sets shutdown_event in finally.
• nothing regenerates and diffs apache_iggy.pyi in ci - php has that gate, python doesn't. no impact here, separate ticket.

[slbotbm]

@hubcio do we want to check the pyi file in ci? i ask because this check will require a complete recompilation of the sdk, and our ci runs are very heavy as it is.

maybe we could instead redesign the ci for ffi sdks instead?

[hubcio]

@slbotbm like we discussed on discord, please propose something via issues or discussions.

[ethanlin01x]

@hubcio Thanks for the review! Also fixed a clippy error while at it.
For the apache_iggy.pyi CI gate, I'll dig into it and open a separate issue for discussion.

[ethanlin01x]

/ready