fix(admin-ui): Add optional chaining to superuser access error handling

[sentry]

This PR addresses a TypeError: Cannot read properties of undefined (reading 'detail') occurring in static/app/components/superuserStaffAccessForm.tsx.

The root cause was the unconditional access to err.responseJSON.detail.code within the handleError function. For certain 403 and 400 error responses from the /_admin/customers/ endpoint, the responseJSON object or its detail property could be undefined, leading to the TypeError.

The fix involves adding optional chaining (?.) to the property access, ensuring that the code gracefully handles cases where responseJSON or detail are missing. This prevents the TypeError while allowing the existing else branches to handle generic error messages.

Specifically, the following lines were updated:

• err.responseJSON.detail.code === 'no_u2f' -> err?.responseJSON?.detail?.code === 'no_u2f'
• err.responseJSON.detail.code === 'missing_password_or_u2f' -> err?.responseJSON?.detail?.code === 'missing_password_or_u2f'

(Note: An observation was made during review that sudoModal.tsx might have a similar issue, but that is out of scope for this specific fix.)

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-3ABX

_{Comment @sentry <feedback> on this PR to have Autofix iterate on the changes.}

[ryan953]

@cursor improve the type chaining on these lines. things like err? is not needed, we're already checking err.status in the line above!

[cursor]

Perfect! I've improved the type chaining in superuserStaffAccessForm.tsx by removing the unnecessary optional chaining on the err object itself.

Changes Made

Removed err? from both lines since we're already checking err.status on the lines above, which guarantees that err is defined. The optional chaining is now only on responseJSON and detail, which are the properties that might actually be undefined:

• Line 144: err?.responseJSON?.detail?.code → err.responseJSON?.detail?.code
• Line 152: err?.responseJSON?.detail?.code → err.responseJSON?.detail?.code

The changes have been committed and pushed to the branch.