Migrate Standalone telemetry from applicationinsights v2 to v3

[craxal]

Problem

src/Standalone/package.json pins applicationinsights@2.5.1. The 2.x line is in maintenance mode; the current major is 3.x, which is a substantial rewrite built on Azure Monitor / OpenTelemetry.

Staying on 2.x leaves us on an old telemetry stack and blocks dependency-hygiene cleanup of an aging direct dependency.

Affected code

Only one consumer: src/Standalone/app/main/Telemetry/AppInsightsTelemetryReporter.ts. It uses APIs that change or disappear in v3:

• appInsights.setup(instrumentationKey) -- v3 expects a connection string instead of a raw instrumentation key.
• Chained config setters (setAutoCollectRequests/Performance/Exceptions/Dependencies(false), setAutoDependencyCorrelation(false), setUseDiskRetryCaching(false)) -- removed. v3 configuration moves to constructor options on the OpenTelemetry distro.
• appInsights.defaultClient -- largely removed; v3 expects an explicit TelemetryClient instance.
• client.commonProperties = {...} (mutated per-event with counter, hashed MAC, locale, dev device id) -- not supported the same way. v3 treats common properties as OpenTelemetry resource attributes set at construction; per-event dynamic values must be sent on the event itself.
• client.trackEvent({ name, properties }) -- still works through the v3 client.

Fix

Rewrite AppInsightsTelemetryReporter against the v3 API:

1. Replace the hard-coded instrumentation key with a connection string. Source it from configuration so the value can be swapped per environment.
2. Construct a TelemetryClient once with the equivalent disabled auto-collectors (or use the Azure Monitor OpenTelemetry distro and disable instrumentations via OTel config).
3. Move static common properties (OS, version, host name, user id, session id) to OTel resource attributes.
4. Continue sending the dynamic per-event fields (order num, hashed MAC, locale, dev device id) as part of each trackEvent properties, not on the client object.
5. Plumb the application.other.enableAppInsightsDiskRetryCache configuration through whatever the v3 equivalent is (likely an exporter option on the OTel distro), or accept that the toggle no longer applies and remove the configuration knob.

Risks / considerations

• v3 pulls the OpenTelemetry stack as transitive deps. We already ship @opentelemetry/* 2.7.x via undici and the Azure SDK; check for version conflicts and bundle-size impact.
• The semantics of per-event vs. per-client common properties differ. Existing dashboards/queries that rely on the current property shape should be validated.
• Connection-string-based routing should be a no-op for production but is worth confirming on a test endpoint first.

Side benefits

• Modernizes a large direct dependency.
• Aligns the app's telemetry stack with the rest of the Azure SDK on OpenTelemetry.
• Removes a slow-moving direct dependency from the supply chain.