Add ClientIp extractor and migrate handlers

[theredspoon]

Summary

Introduces a tuwunel-internal ClientIp extractor in src/api/client_ip.rs and migrates all 22 API handler call sites away from axum_client_ip::InsecureClientIp.

This change is plumbing only. It is designed to be a no-op for every existing deployment:

• The extractor default branch delegates to InsecureClientIp, preserving today's header scan chain and ConnectInfo fallback exactly.
• A new marker, ConfiguredIpSource, gates the SecureClientIp branch. Nothing in this change installs that marker; Add configurable ip_source for client IP resolution. #429 installs it only when ip_source is configured.
• The existing SecureClientIpSource::ConnectInfo extension installed by src/router/layers.rs is intentionally untouched and ignored by this extractor, so Unix-socket deployments (Unix listener can't read client ip #310) remain unaffected.

Two-PR series

This is the first PR in a two-PR effort for configurable, spoofing-resistant client IP resolution:

• Add ClientIp extractor and migrate handlers #428 (this PR): introduces the internal ClientIp extractor and migrates handlers to use it, while preserving current behavior by default.
• Add configurable ip_source for client IP resolution. #429: builds on this extractor by adding the optional ip_source config field, startup warnings for trusted-proxy header sources, reload protection, router-layer installation of ConfiguredIpSource, and deployment documentation.

Keeping this split lets reviewers verify the mechanical extractor migration independently from the user-facing configuration and documentation work. #429 should land after this PR.

Test plan

• cargo check -p tuwunel_api
• cargo clippy -p tuwunel_api --no-deps -- -D warnings
• rustup run nightly rustfmt --check on touched files
• cargo test -p tuwunel_api client_ip
• Unit tests in src/api/client_ip.rs cover fallback and configured paths, malformed headers, IPv6, XFF priority, configured-header absence, and the auto-installed SecureClientIpSource regression.
• Manual smoke: start tuwunel, hit /_matrix/client/versions, confirm tracing emits the connecting IP as today.

[theredspoon]

Update after the force-push:

• The failing upstream job was Audit, caused by RUSTSEC-2026-0104 against rustls-webpki 0.103.12.
• I amended this PR's single commit to update Cargo.lock to rustls-webpki 0.103.13.
• Current Add ClientIp extractor and migrate handlers #428 head: b0b15dca4e3e5fb2b0e323bab15e98e643ac2207.

Local validation performed:

• Ran the Docker clippy bake target against the PR stack with the same relevant CI matrix shape: cargo_profiles=["test"], feat_sets=["all"], rust_toolchains=["nightly"], Debian testing-slim, Rust target x86_64-unknown-linux-gnu, sys target x86_64-v1-linux-gnu. It completed successfully with the CI -D warnings Clippy path. Local note: I set cargo_installs=cargo-chef for that Clippy run so the build skipped unrelated cargo helper installs and reached the lint step.
• Ran cargo audit --stale --deny yanked --deny unsound --deny unmaintained --deny warnings --color never locally with cargo-audit 0.22.1; it exited successfully on the restacked branch containing this lockfile update.

Constraints / caveats:

• The full Docker audit bake target did not complete locally because the Docker/Colima environment exhausted host disk space and then rustup hit Input/output error (os error 5) before the advisory scan. I used the host cargo-audit command above to verify the actual advisory condition instead.
• Fresh GitHub Actions runs after the force-push are currently action_required with jobs: [], so upstream CI has not actually rerun yet and likely needs maintainer approval/re-run for the forked PR.

[theredspoon]

Quick maintainer nudge: after the force-push/restack, the current workflow runs for #428 and #429 look like they need maintainer approval again.

[theredspoon]

Quick update on the rerun for this PR (#428): the current red is rust-sdk-integ bench failing in tests::room::test_event_with_context, where the SDK received a RoomEncrypted event instead of the expected decrypted RoomMessage.

That is a different failure from the earlier room_privacy timeout, and #429 passed the same rust-sdk-integ jobs, so this still looks more like unstable integration-test behavior than a clear regression in #428's touched code.

I’m not planning to make further changes to #428 unless a failing test points to a concrete issue in the PR itself, so from my side the remaining options are either rerunning to see whether the failure reproduces or merging #429 and closing out/superseding this PR.

[jevolk]

I'm sorry for not addressing this sooner. These flakes are not your fault and no further action has been required. I sincerely appreciate your effort here 🙏🏻 and I'll be attending to this very shortly. If in any case there is a delay and (considering the broad scope of the diff) a conflict forms, I will take responsibility for resolving that. Thank you! 🫡