OpenRouter error telemetry emits inconsistent provider value ("OpenRouter" vs "openrouter") #1302

Context

PR #1165 canonicalized the OpenRouter ApiProviderError calls to providerIdentifiers.openrouter. See the pending-review note on src/api/providers/openrouter.ts:201.

providerIdentifiers.openrouter is "openrouter" (lowercase). The class field this.providerName is "OpenRouter" (capitalized, openrouter.ts:147). The two values now disagree for the same error event.

Problem

ApiProviderError.provider flows into telemetry through extractApiProviderErrorProperties (packages/types/src/telemetry.ts:475). PR #1165 changed the emitted provider value for OpenRouter errors from "OpenRouter" to "openrouter". This has two effects:

1. Telemetry continuity. A Sentry or PostHog series, query, or alert that groups OpenRouter errors on provider = "OpenRouter" stops matching after deploy. The old series ends and a new "openrouter" series starts.
2. Per-event label divergence. The same catch blocks still call handleOpenAIError(error, this.providerName) at openrouter.ts:368, 379, 638, 649, which keeps "OpenRouter" for the user-facing message. So one error now carries two spellings: "openrouter" in telemetry, "OpenRouter" in the message.

This is the only substitution in PR #1165 that changed a value. All other provider identifiers mapped to strings equal to the literals they replaced.

Fix (fast follow)

Pick one:

1. Keep the lowercase telemetry value. Also change handleOpenAIError(error, this.providerName) to providerIdentifiers.openrouter at the four sites above, so both sinks agree. Update or add an OR clause to any dashboard or alert keyed on the old "OpenRouter" value.
2. Preserve the historical value. Revert the five ApiProviderError provider arguments back to this.providerName.

Either way, add a comment on the providerName field ("display name, not the telemetry identifier"), or an independent test pin on the emitted casing. The current assertions in openrouter.spec.ts reference providerIdentifiers.openrouter on both sides, so they cannot catch a future drift in the emitted value.

References

• PR: refactor(providers): canonicalize model-router calls #1165
• src/api/providers/openrouter.ts:147, 201, 356, 368, 374, 379, 626, 638, 644, 649
• packages/types/src/telemetry.ts:475
• packages/types/src/provider-identifiers.ts:7
• src/api/providers/__tests__/openrouter.spec.ts:354