fix(integrations): Prevent TypeError when integration provider is undefined

[sentry]

This PR fixes a TypeError: undefined is not an object (evaluating 'N?.provider.key') that occurred on the integration configuration page (/settings/integrations/:providerKey/:integrationId/).

The root cause was in static/app/views/settings/organizationIntegrations/configureIntegration.tsx line 186, where integration?.provider.key was used. The optional chaining only guarded against integration being nullish, but not integration.provider. If an integration object was present (e.g., from cached data or an API response without a provider field) but integration.provider was undefined, accessing .key would throw a TypeError.

The fix involves adding an additional optional chain: changing integration?.provider.key to integration?.provider?.key. This ensures that the access to .key is safely short-circuited if integration.provider is undefined.

A new test case has been added to configureIntegration.spec.tsx to cover this scenario, ensuring the component renders gracefully without throwing an error when integration.provider is undefined.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

Fixes JAVASCRIPT-3B9D

_{@sentry <feedback>: Autofix iterates on these changes
@sentry stop iterating: Autofix stops iterating on this run}

_{This PR was automatically generated by Sentry. You can adjust this setting at any time.}