[RUM-9335] Fix missing application.id in "Session Ended" telemetry

[saraSr5]

What and why?

"Session Ended" telemetry was sometimes missing application.id. The metric is emitted at the exact moment a RUM session stops existing — after an inactivity timeout, or after stopSession() — and TelemetryReceiver derived application.id from the RUM session context, which is nil once there is no session.

This matters because SDK telemetry is consumed per RUM application: an event without application.id cannot be attributed to an app. The loss was also not random — it hit exactly the sessions that ended by timeout or by stopSession(), which biases any analysis of how sessions end. It additionally forced "Session Ended" telemetry to stay disabled in the integration test fixtures, now removed.

How?

TelemetryReceiver now receives applicationID at init from RUMFeature and uses it directly, instead of reading it from the session context.

The RUM application ID is SDK configuration — known upfront, immutable for the life of the instance, and not session state. Sourcing it from a per-session context was the original modelling error. CrashReportReceiver, declared a few lines below in the same receiver list in RUMFeature, already takes applicationID at init for exactly the same reason: crash reports are also emitted when no session is active. TelemetryReceiver was the outlier.

RUMCoreContext is unchanged, so the modules that consume it (Logs, Trace, SessionReplay, Profiling, WebViewTracking, Flags, NetworkInstrumentation) are unaffected.

The neighbouring fields are deliberately left as they were: session and action are genuinely session state and must stay nil when no session exists. Only application becomes unconditional.

Relation to #2324. That PR added an applicationIDOverride mirroring sessionIDOverride, and was closed in favour of "a real fix than a workaround". An override exists to report a value that differs from the current one — necessary for session.id, because by emission time the context already holds the new session, but meaningless for application.id, which never changes. Injection is also harder to get wrong: a future metric cannot forget to set an attribute it does not need.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes
• Add Objective-C interface for public APIs - see our guidelines (internal)
• Run make api-surface when adding new APIs

[saraSr5]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: 3c55ae5568

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".