feat(python): add HttpConfig transport configuration

[saie-ch]

Which issue does this PR address?

Relates to #2835.

Rationale

Python's HTTP transport was only reachable through the untested from_connection_string() path, with no config object like TCP got in #3776.

Added HttpConfig, accepted by IggyClient(...) alongside a plain address and
TcpConfig, mirroring the TcpConfig pattern. An earlier revision exposed this
as an IggyClient.http(...) classmethod; that was dropped in favour of widening
the existing constructor union, per review.

Local Execution

• cargo fmt, cargo clippy --all-targets -- -D warnings, ruff, pyrefly,
  markdownlint all clean
• apache_iggy.pyi regenerated via stub_gen and in sync
• Full Python suite passes against a local server (524 passed; test_tls.py
  needs Docker)
• Both getting-started examples run, including with the HTTP config swap applied
• Pre-commit hooks ran

AI Usage

Claude Sonnet 5 and Claude Opus 5

[github-actions]

Thanks for the PR. It is labeled S-waiting-on-review and queued for review.

Slash commands (own line, regular comment) move it around the queue:

• /ready - back to S-waiting-on-review after addressing feedback
• /author - flip to S-waiting-on-author while you finish changes
• /request-review @user-or-team - request a reviewer

See CONTRIBUTING.md for details.

[codecov]

Codecov Report

❌ Patch coverage is 98.82353% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 85.92%. Comparing base (b87b6a6) to head (63dba7b).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
foreign/python/src/config.rs	98.73%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3992      +/-   ##
============================================
+ Coverage     85.90%   85.92%   +0.02%     
  Complexity     1431     1431              
============================================
  Files          1244     1246       +2     
  Lines        192435   192662     +227     
  Branches     158133   158293     +160     
============================================
+ Hits         165307   165553     +246     
+ Misses        23037    22989      -48     
- Partials       4091     4120      +29     

Components	Coverage Δ
Rust Core	86.84% <75.82%> (+0.02%)	⬆️
Java SDK	67.52% <ø> (ø)
C# SDK	76.99% <ø> (+0.01%)	⬆️
Python SDK	90.73% <98.82%> (+0.18%)	⬆️
PHP SDK	85.65% <ø> (ø)
Node SDK	96.26% <ø> (+<0.01%)	⬆️
Go SDK	69.43% <ø> (+0.03%)	⬆️

Files with missing lines	Coverage Δ
foreign/python/src/client.rs	99.87% <100.00%> (+<0.01%)	⬆️
foreign/python/src/lib.rs	100.00% <100.00%> (ø)
foreign/python/src/config.rs	97.84% <98.73%> (+0.08%)	⬆️

... and 39 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]

I ran this locally and it works well. I have a few suggestions, mostly around tests and docs.

[saie-ch]

@ethanlin01x Could you please check now.

[slbotbm]

As was requested in the websocket pr: fold the http config example into existing examples as comments, and change the exposed API signature to IggyClient( ... | HttpConfig | ...).

[saie-ch]

/ready

[hubcio]

my main worry is that HTTP now reads as a first-class transport without saying what it cannot do, and two of the gaps are silent.

A few findings land on code this PR doesn't touch, so I couldn't attach them inline:

• core/sdk/src/http/http_client.rs:98,117,137,157,173,192,213 - the access_token read guard is held across the whole .send().await in all seven verbs, including every retry backoff. IggyRwLock is write-preferring, so one login_user queues behind in-flight requests and then blocks new readers. There's no request timeout either (:272 is a bare reqwest::Client::new()), so a hung server pins the guard with no bound. refresh_access_token at :312-320 already does the clone-then-drop thing.
• foreign/python/README.md:137 - lead-in still says IggyClient takes "either a server address or a TcpConfig", 34 lines above the new paragraph.
• .github/actions/python-maturin/pre-merge/action.yml:167 - ${{ steps.iggy.outputs.address }} isn't an output server-start declares, so that line logs an empty address. tcp_address is the one you want.
• foreign/python/src/client.rs:1117 - consumer_group() is the one HTTP-hostile entry point with no HTTP note; join and leave both carry one.
• core/common/src/types/configuration/http_config/http_client_config.rs:47-55 - separate from this PR, but worth an issue: the HTTP connection string requires user:pass@ and then drops it, so from_connection_string("iggy+http://iggy:iggy@...") gives an unauthenticated client. tcp, quic and websocket all carry auto_login through; http is the only one that doesn't. Same line hardcodes http://, so HttpConfig is the only Python route to an https endpoint.
• core/sdk/src/clients/client.rs:358 - the doctest connection string has no @, so it can't parse. It's no_run, so nothing catches it.

Already accepted