fix(core): extension lifecycle events ignore privacy.usageStatisticsEnabled and are uploaded to RUM #12770

What happened?

With privacy.usageStatisticsEnabled: false (set in system settings) and
QWEN_USAGE_STATISTICS_ENABLED=0, extension lifecycle events (install, uninstall, update,
enable, disable) are still queued for the usage-statistics (RUM) uploader.

Root cause is in packages/core/src/extension/extensionManager.ts:

function getTelemetryConfig(cwd: string, telemetrySettings?: TelemetrySettings) {
  const config = new Config({
    telemetry: telemetrySettings,
    interactive: false,
    targetDir: cwd,
    cwd,
    model: '',
    debugMode: false,
    chatRecording: false,
  });
  return config;
}

usageStatisticsEnabled is not passed, so Config falls back to
params.usageStatisticsEnabled ?? true. logExtensionInstallEvent / logExtensionEnable /
etc. in telemetry/loggers.ts call QwenLogger.getInstance(config), which only returns
undefined when config.getUsageStatisticsEnabled() is false — so with this throwaway config
the logger is always created and the event is enqueued.

The opt-out is resolved (QWEN_USAGE_STATISTICS_ENABLED ?? settings.privacy.usageStatisticsEnabled ?? true)
only when the main session Config is built from settings; ExtensionManager receives only
telemetrySettings, so neither the setting nor the env override reaches this path. The same
throwaway config also carries no proxy, so the upload does not go through the configured proxy.

Observed on v0.24.5 (standalone); the code is unchanged on main.

What did you expect to happen?

With the usage-statistics opt-out in effect (setting or env), no extension event is sent
to RUM — same as every other usage-statistics event.

Steps to reproduce

1. Set "privacy": { "usageStatisticsEnabled": false } in settings (or QWEN_USAGE_STATISTICS_ENABLED=0).
2. In a long-running process (interactive session, qwen serve / Desktop daemon), enable or
   disable an extension twice more than 60 s apart (or install/update one).
3. The RUM flush timer fires and the extension events (extension name, source, version,
   installation-derived user id) are posted to the RUM endpoint.

A one-shot qwen extensions install usually exits before the 60 s flush, which is probably
why this went unnoticed.

Suggested fix

Pass the resolved opt-out (and proxy) into ExtensionManager alongside telemetrySettings
and forward them in getTelemetryConfig, e.g.:

new Config({ telemetry: telemetrySettings, usageStatisticsEnabled, proxy, ... })

— or have getTelemetryConfig reuse the host session's Config instead of constructing a
new one. A regression test in extensionManager.test.ts asserting that no QwenLogger
instance is created when usage statistics are disabled would lock it in.

Related: #12600 / #12604 (same class of bug for --bare).

Why this matters

I run managed installations where usage statistics are disabled by policy in system settings.
Any event that bypasses the opt-out is an unexpected outbound call to a third-party endpoint,
and because it bypasses the proxy it is also invisible to network egress controls.

Client information

• Qwen Code v0.24.5 (standalone), macOS; also applies to Linux/Windows (platform-independent code path)
• Auth: OpenAI-compatible provider