Instrument the auth client's network calls in Datadog

[StylianosGakis]

Pass the okhttp engine to the ktor client used for auth.
This allows for it to be hooked up to the Datadog setup so we get tracing properly there too.

More context in https://claude.ai/code/artifact/11bf9662-fb53-4507-bda7-7be7e0dea6a3

🤖 AI description:

:authlib builds its own Ktor client and has never carried a Datadog dependency, so every login, OTP and token-exchange call is invisible to RUM. Over 7 days in prod, auth.prod.hedvigit.com showed 634 resource events from the shared client's /member-authorization-codes and 4 from :authlib, all of them from 12.11.6. Auth failures reached us only as @error.source:logger prose with no status code and no duration, which is why five 504s on /member-login needed an investigation rather than a glance.

This hands :authlib an engine that is already instrumented, and leaves it Datadog-free. :datadog-android builds it, restoring the three pieces 7d14888e81 deleted. The auth host also joins setFirstPartyHosts and the engine's traced hosts.

Instrumenting at the OkHttp layer rather than adding the Datadog Ktor plugin is deliberate, and it is also what brings back the per-request timing breakdown. The Ktor plugin keys each RUM resource with its own uuid4() stored in a Ktor attribute, which DatadogEventListener cannot see, so timings can never attach to it. :network-clients is untouched and keeps the plugin.

Worth a reviewer's eye

The constructor shape in NetworkAuthRepository. Kotlin/Native does not carry default parameter values into the Obj-C API, so engine: HttpClientEngine? = null on the existing constructor would export initWithEnvironment:additionalHttpHeadersProvider:engine: and break Ugglan's AuthenticationClientAuthLib.swift at the next umbrella bump. Hence an internal primary constructor plus a public secondary one that keeps the original two parameters, and a JVM-only networkAuthRepositoryWithEngine so HttpClientEngine never reaches the shared surface.

Verification

Static:

• Affected-module unit tests and the full :app:test pass. :app:compileDebugKotlin, :authlib:compileKotlinIosSimulatorArm64 and ktlintCheck pass, including the newly merged NamespaceImportRule.
• NetworkAuthRepositoryEngineTest asserts the caller-supplied engine actually receives the request, and that the environment reaches the right host. Mutation-checked: removing the engine branch from buildKtorClient makes it fail, restoring it makes it pass.
• HedvigShared.framework was relinked on a clean tree and with the change, and the generated Obj-C header is byte-identical. NetworkAuthRepository keeps its single init(environment:additionalHttpHeadersProvider:), and neither networkAuthRepositoryWithEngine nor baseUrl appears at all. This branch does not touch the iOS API surface, so Ugglan is unaffected by construction rather than by inspection.

On device, debug build 14.4.7 on a Pixel 6 Pro, full logout and BankID login against staging:

• Logout, POST /member-login, status polling and /oauth/token all succeeded. Zero RUM errors across the episode.
• All four auth calls now produce RUM resources, where the same endpoints produced none before: /member-login, /member-login/{id} twice, and /oauth/token, all status 200.
• They carry dns, download and size, and provider.type: first party, confirming both the event listener and the setFirstPartyHosts change. connect, ssl and first_byte are absent on these, consistent with a pooled connection.
• Control from the same session: apollo-router.dev.hedvigit.com resources, which still go through the Ktor plugin, have dns, size and download all null. Same app, same minute, which is a clean A/B on the timing claim.

The Datadog side is already done

Handled outside this PR on 9 September, so nothing else is needed once this ships. Both login metrics are now event_type: resource counting POST /member-login on the auth host for real users, failures are those same events filtered to [500 TO 599], and the SLO window moved from 7 to 30 days. The SLO keeps its id and monitor 93408872 keeps its Slack routing.

Two Datadog behaviours found on the way, worth knowing: event_type cannot be updated on a generated metric (the PATCH returns 200 and silently discards it), and deleting a generated metric does not purge its computed timeseries.

Why a planning doc is in this diff

docs/plans/2026-08-27-datadog-android-metric-recovery.md loses 143 lines, which is unrelated to the
Kotlin change and worth explaining rather than skimming past.

That doc was actively dangerous once the Datadog side landed. It listed android.login.network.count
and android.login.network.error among its pending edits with ready-to-paste @view.name target
filters and instructions to apply them. Following it would have overwritten the new auth-host filters
and put the login denominator back to counting apollo-router traffic. The snippets are removed rather
than annotated, so there is nothing left to paste.

While in there, three things that were carrying no weight came out. Its rollback appendix recorded ten
pre-change filter definitions on the stated grounds that Datadog keeps no history of a generated
metric's definition, which was true when written and stopped being true when 9e5525fc27 landed; it
is now a pointer to that commit. The app-side narrative is in #3104 and is reduced to a summary. And
eight metrics that had read zero since March, held only because nobody knew whether deleting a
generated metric purges its timeseries, are deleted; it does not, and their definitions are in the
message of the commit that deleted them.

No behaviour anywhere depends on that file. Skipping it costs a reviewer nothing.