RFC: RestSharp.Maui companion package for platform-specific quirks

Motivation

A growing set of MAUI / mobile-specific gotchas can't be fixed in core RestSharp because:

• Core targets netstandard2.0 / net8.0+ and must remain free of iOS / Android workload dependencies.
• Platform fixes often require calling into Foundation / NSURLSession / Java.Net types that only exist under TFM-specific workloads (net9.0-ios, net9.0-android, etc.).
• Documenting the workarounds (see #2387) helps, but every consumer ends up copy-pasting the same recipe.

A small TFM-targeted companion package could collect these recipes as one-liner extension methods.

Proposed surface

// RestSharp.Maui
public static class RestClientOptionsExtensions {
    /// <summary>
    /// Configures the underlying handler to suppress NSURLSession's cookie storage,
    /// so Set-Cookie headers reach RestSharp's per-request parser intact.
    /// Multi-tenant safe — no shared cookie state at any layer.
    /// </summary>
    public static RestClientOptions UseIosCookieFix(this RestClientOptions options);

    // Room for future fixes:
    // - UseIosCertificatePinning(...)
    // - UseAndroidNetworkSecurityConfig(...)
    // - UseEphemeralNetworking()
}

Usage in a MAUI app:

var options = new RestClientOptions(baseUrl).UseIosCookieFix();

Open questions

1. Naming. RestSharp.Maui vs RestSharp.Platforms vs separate RestSharp.iOS + RestSharp.Android packages. I lean toward RestSharp.Maui — single package, MAUI is the dominant consumer of platform-specific HTTP quirks.
2. TFM matrix. Probably net8.0-ios, net9.0-ios, net10.0-ios, net8.0-android, net9.0-android, net10.0-android, plus netstandard2.0 no-op fallbacks so consumers can reference it from shared projects without conditional compilation.
3. Maintenance burden. Every iOS / Android SDK bump may need a sanity check. Worth it only if 2-3+ platform fixes accumulate. Today we'd ship with just UseIosCookieFix.
4. Discovery. Would need a README pointer and a docs section explaining when to reach for it. Risk: people who don't read docs still hit the original bug.

Decision needed

• Ship now with a single helper (UseIosCookieFix) covering #2168 / #2385?
• Wait until 2-3 platform fixes accumulate to justify the package?
• Reject and keep all platform recipes in docs only?

Tracking: depends on #2387 (docs landing first) and follows from the design discussion in #2168.

Start by reviewing dependent issue #2387 and the design discussion in #2168, then compare the proposed coverage for #2168 and #2385. No implementation files or tests are named. Done means reaching a decision on whether to create the companion package, its naming and TFM matrix, and the initial scope.