Support platform-native TLS backend (SChannel on Windows, OpenSSL on Linux) via `crypto-native-tls` feature

[AaronRM]

Pre-filing checklist

• I searched existing issues and didn't find a duplicate

Component(s)

Rust OTAP dataflow (rust/otap-dataflow/)

Description

Problem

PR #2269 introduced pluggable rustls crypto providers via mutually exclusive feature flags: crypto-ring, crypto-aws-lc, crypto-openssl. All three use rustls as the TLS implementation and differ only in the underlying crypto provider.

This works well for the standalone df_engine binary, but creates significant build complexity when attempting to link otap-df-otap as a library into a C++ host process esp. across multiple platforms. e.g.:

• crypto-aws-lc fails on Windows aarch64: aws-lc-sys's GAS-syntax .S assembly files are silently ignored by cl.exe, producing missing object files (LNK1181).
• crypto-aws-lc on Windows x86_64 requires /force:guardehcont linker workarounds because NASM-assembled objects lack /guard:ehcont metadata.
• crypto-ring works on all platforms but still bundles its own crypto library (ring compiles C/asm from source), adding build complexity and binary size.
• crypto-openssl requires OpenSSL on Windows (not a system library shipped in Windows).

Proposed solution

Add a new crypto-native-tls feature flag that uses the platform's native TLS stack instead of rustls + a compiled crypto provider:

Platform	Backend
Windows	SChannel (built-in, zero dependencies)
Linux	OpenSSL (system library)
macOS	Security.framework (built-in)

This is the same pattern used by geneva-uploader and the Azure SDK's reqwest 0.12 dependency already in otel-arrow's dependency tree.

Scope

• Add crypto-native-tls feature to otap-df-otap and the workspace root
• When enabled, reqwest uses its native-tls feature instead of rustls-no-provider
• install_crypto_provider() becomes a no-op (no rustls CryptoProvider needed)
• The HTTP client builder selects .use_native_tls() instead of .use_rustls_tls()
• Add CI check for the new feature

Limitations

• crypto-native-tls covers client-side HTTP/HTTPS connections only (reqwest-based: OTLP HTTP exporter, Azure Monitor exporter, Geneva uploader)
• Server-side gRPC TLS (experimental-tls feature) still requires a rustls crypto provider (crypto-ring, crypto-aws-lc, or crypto-openssl). tonic 0.14 does not support native-tls backends. For the embedding use case this is acceptable since the host process handles networking.
• The default feature set remains crypto-ring. There should be no breaking changes for existing users.

Additional Context

No response