Send usage telemetry to Scarf as well as App Insights

[MatiasFernandez]

Sends GemDB's seven usage events to Scarf as well as App Insights. App Insights masks IP addresses, so it can't tell us which companies and organisations use GemDB. Scarf can, and anyone can read its dashboards. App Insights is unchanged.

How it works

• One send site, two sinks. send() in telemetry.ts still goes to App Insights and now also calls a second TelemetryLogger created with a ScarfSender. Opt-out is VS Code's own telemetry setting, enforced by createTelemetryLogger for both, so there's no consent check of our own.
• Production only. Scarf's logger exists only when extensionMode is Production, so F5 and test runs never reach it and everything in Scarf is production data.
• One GET per event, sent to https://gemdb.gateway.scarf.sh/gemdb/code/telemetry?event=<name>&…. Every GemDB property and measure goes as a query parameter, so a new one needs no change for Scarf. Of the common.* properties, only five go, from an allowlist: machine id, extension version, OS, VS Code version and remote name. Everything arrives as a string.
• common.os is added explicitly. It isn't one of VS Code's own common properties: @vscode/extension-telemetry adds it, to its own logger only. The Scarf logger passes it through additionalCommonProperties, the same way the package does.
• The event name has a prefix that gets stripped. VS Code adds gemtalksystems.gemdb/ to the front of every event name before a sender sees it. ScarfSender removes it, so event=activated, not event=gemtalksystems.gemdb/activated.
• The network sits behind its own module. scarfTransport.ts holds the https.get (3 s timeout, fire-and-forget, every error swallowed, including a synchronous throw). src/__mocks__/setup.ts swaps it for a recorder in every test file. fakeExtensionContext is a Production context, so without this, a dozen existing suites would send real events to Scarf. Only scarfTransport.test.ts runs the real one, through vi.importActual with https mocked.
• The fake logger behaves more like VS Code. It now hands events to a real sender with the name prefix, adds only the additionalCommonProperties each logger was created with, and lets common properties win a key collision. That is what makes a missing common.os fail a test.
• The shell bundle is still guarded. The eslint import restriction and the esbuild metafile check now cover scarfTransport.ts as well as telemetry.ts, since the transport sends with no consent check of its own. grep gateway.scarf.sh out/gemdb-shell.js finds nothing.

Worth knowing when reading Scarf's data

In a remote window (SSH, Codespaces) GemDB runs on the remote machine, so a cloud host reads as Amazon, Microsoft or Google rather than the user's employer. docs/telemetry.md says to leave out events whose common.remotename is set when counting companies.

Before merge

USAGE_DATA.md has TODO comments for things we need Scarf to confirm:

• the raw IP address is discarded after the company and location matching
• the region the data is stored in, and how long it is kept
• Scarf can delete events by a common.vscodemachineid value
• our Scarf plan includes company enrichment

Not yet tested

• An end-to-end run with a packaged .vsix in a normal profile, checking that events arrive in Scarf, that nothing arrives with telemetry.telemetryLevel: off, and that nothing arrives from dev:fresh.

🤖 Generated with Claude Code