[Flutter] Add network request/response logging (manual + automatic)

[iainfinlayson]

Goal

Fills one of the alpha's documented gaps: no HttpRequestInfo/HttpResponseInfo equivalent was exposed in the Flutter plugin. Adds two complementary APIs:

1. Manual: Capture.logNetworkRequest(...) / Capture.logNetworkResponse(...), bridged to the native HttpRequestInfo/HttpResponseInfo APIs on both platforms.
2. Automatic: Capture.enableNetworkInstrumentation(), a dart:io HttpOverrides that captures requests/responses through the default HTTP stack with zero code changes at each call site — calls the exact same manual API under the hood, no new native code.

Depends on #1186 (stacked on it — the example app's Android build doesn't work without that fix). Merge #1186 first; this diff will shrink once that lands.

Manual API

• platform/capture_flutter/lib/src/network.dart — HttpRequestInfo, HttpResponse, HttpRequestMetrics, HttpUrlPath, HttpResult. Includes a small dependency-free UUID v4 generator for spanId.
• Android (CaptureFlutterPlugin.kt) and both iOS plugin copies bridge these to native. Stateless design — each call reconstructs the request/response as a native value type rather than holding a live object across calls, since these are value types compared structurally, not by reference (no leak-prone map like activeSpans). Durations/metrics are milliseconds throughout the Dart API; the iOS bridge converts to TimeInterval seconds for the native call.

Automatic instrumentation

• platform/capture_flutter/lib/src/network_instrumentation.dart — Capture.enableNetworkInstrumentation() installs an HttpOverrides wrapping HttpClient/HttpClientRequest/HttpClientResponse. Implemented against the exact dart:io interfaces (read directly from the local Dart SDK source, not from memory, to avoid subtly wrong overrides). Chains any HttpOverrides the app already set (e.g. cert pinning) rather than clobbering it. Reads the x-capture-path-template header — the same convention the shop demos already use — for path-template collapsing, since automatic instrumentation has no other way to infer one.

• Calls the exact same Capture.logNetworkRequest/logNetworkResponse Dart API from the manual path above — no additional native Kotlin/Swift code. Both paths converge on the identical handleLogNetworkRequest/handleLogNetworkResponse native handlers.

• README documents an explicit "when automatic works vs. when manual is required" table, mirroring the native SDKs' own split (OkHttp EventListener/URLSession swizzling vs. their own manual HttpRequestInfo/HttpResponseInfo APIs):

  	Automatic	Manual
  Raw dart:io HttpClient, package:http's default client, dio's default adapter (mobile)	✅	—
  dio with CronetHttpAdapter/CupertinoHttpAdapter, or any client bypassing dart:io	❌ invisible to HttpOverrides	✅ required
  Native SDKs making their own requests (Firebase, ad/payment SDKs)	❌ never touches Dart	✅ required
  WebViews	❌ requests run inside the native WebView engine	Not yet bridged to Flutter at all
  HttpClient created before enableNetworkInstrumentation()	❌ already built via the un-overridden factory	✅ required for that instance
  Networking in a different isolate	❌ per-isolate override	✅ required, or call it again in that isolate
  Path template collapsing	Only via x-capture-path-template header	Pass HttpUrlPath(value, template:) directly

Bugs found and fixed along the way

• iOS plugin drift: the SPM copy (ios/capture_flutter/Sources/capture_flutter/CaptureFlutterPlugin.swift) was missing setEntityId/clearEntityId, which [Flutter] Add setEntity/clearEntity + bump version #1178 only added to the CocoaPods copy (ios/Classes/CaptureFlutterPlugin.swift). Re-synced for now; worth consolidating the two copies eventually so this can't drift again.
• Unsigned release APK: examples/flutter/android/app/build.gradle.kts's release build type had no signingConfig — flutter build apk --release silently produced a genuinely unsigned APK (INSTALL_PARSE_FAILED_NO_CERTIFICATES on install). Fixed by signing with the debug key, matching the sa-public shop demo.

Example app

Added two buttons to examples/flutter: "Network Request (ping google)" (manual) and "Network Request — auto (ping google)" (zero manual logging calls, relies entirely on enableNetworkInstrumentation()). Worth noting: no existing example app in this repo — Android, iOS, or any bitdrift-shop variant — demonstrates the manual network API interactively; they all rely on automatic OkHttp/URLSession instrumentation. This seemed like the only way to actually exercise both new APIs by hand.

Verification

Built, installed, and ran on both platforms (Android emulator + iOS Simulator):

• Manual path: tapped the button, confirmed in the bitdrift session timeline (staging tenant) — HTTPRequest/HTTPResponse entries present, correct _status_code, _result, _duration_ms, _request.* correlation fields, built-in network matchers picked it up.
• Automatic path: tapped the "auto" button (a plain HttpClient GET with zero manual logging calls) on both platforms — real 200 response with correct byte count, zero Dart-level exceptions, zero platform-channel errors, on both the synchronous request-time log call and the unawaited async response-time log call.

---

• CHANGELOG.md's "Unreleased" section has been updated, if applicable. (Flutter-specific changes go in platform/capture_flutter/ALPHA_RELEASES.md instead, per its own convention — updated there for both APIs.)

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[iainfinlayson]

I have read the CLA Document and I hereby sign the CLA