fix: unbreak the login webview shipped in 2.5.0

[ashishrp-aws]

Customer-reported: black login view with "Webview error" on IdC sign-in in 2.5.0

Diagnosed from the extension log of a live repro. The logged failure:

[error] webviewId="aws.amazonq.AmazonCommonAuth": Error: Webview error
 -> Error: Webview backend command failed: "setUiReady()"
 -> TypeError: Cannot read properties of undefined (reading 'start')

This PR contains two fixes. One is the demonstrated cause of the reported failure; the other is a real packaging regression in the shipped 2.5.0 artifact that is fixed here as prevention, but is most likely not what customers are hitting. An earlier revision of this description claimed the two compound; tracing root.vue's load sequence disproved that, so the claim is corrected rather than left to stand.

The demonstrated cause: setDidLoad crashes on any late load

The captured timeline:

Time	Event
21:33:24	extension activates; heavy startup under way (LSP download, MCP server init, token refresh)
webview opens	setup() arms a 10-second load timeout; on expiry it clears loadMetadata, assuming the load failed
~21:33 → 21:34	root.vue's created() awaits client.refreshAuthState() before reporting readiness, and that call sits on AuthUtil.getChatAuthState() — ~44 seconds on this busy startup. The view renders nothing while it waits: this wait is the black screen
21:34:08	readiness finally reported → setUiReady → setDidLoad dereferences loadMetadata!.start, but the timeout consumed it 30+ seconds earlier → TypeError → VS Code shows the webview error banner
21:34:11	user starts IdC sign-in (the error predates auth — IdC is implicated because it is where users linger on this view)

A second, deterministic trigger — no slowness required

Found while investigating why local testing (repeated IdC logout/login) also produced the error. The login webview is retainContextWhenHidden: true, so one webview instance lives across auth cycles. root.vue reports readiness once per page kind (auth, selectProfile) per webview lifetime, but the backend has a single loadMetadata slot: armed at setup(), re-armed only by enterProfileSelection(), and consumed (= undefined) by any successful setDidLoad.

So: webview resolves while in PENDING_PROFILE_SELECTION (every IdC sign-in passes through it) → the profile page reports first and consumes the metadata → user signs out → the LOGIN page renders for its first time in this webview's lifetime and reports readiness → loadMetadata is undefined → same TypeError. Repeated IdC logout/login cycles reliably produce this ordering. It also explains why field reports cluster on IdC: Builder ID skips profile selection, so it can only hit the timeout variant.

The error path (setLoadFailure) already optional-chains; only the success path could throw. Fix (covers both triggers): when the metadata has already been consumed — by the timeout or by the other page kind — emit toolkit_didLoadModule with reason: 'LoadReportedAfterMetadataCleared' and no duration, and return. A late or re-ordered successful load is a success, not a crash.

Suggested regression test for the checklist, deterministic and environment-free: IdC sign-in → do not select a profile → sign out → confirm no webview error banner.

The prevented regression: the login Vue bundle shipped mis-packaged

esbuild-loader 4.5.0 (from the 2.5.0 dependency remediation) infers format: 'iife' when webpack's compile target is web and the minifier target is not esnext, wrapping the whole bundle in a CommonJS helper and rewriting top-level this, which defeats output.libraryTarget: 'this'. In the shipped 2.5.0 VSIX the login bundle is the only wrapped one:

bundle	shipped shape
feedback/vue/index.js	clean
codewhisperer/vue/index.js	clean
codewhisperer/views/securityIssue/vue/index.js	clean
login/webview/vue/amazonq/index.js	CJS-wrapped

Why it is probably not the customer failure: the wrapper's factory self-invokes at the end of the bundle (po();), so the login app still executes and mounts, and unlike the chat webview nothing on the login page consumes the global export the wrapper destroys. Verified against the installed artifact.

Why it is fixed anyway: the identical wrapper does break consumers that resolve exports off the global — it broke the chat webview in pre-release testing (HybridChatAdapter is not defined, blank panel) and the same loader upgrade was reverted once before for breaking mynah-ui (91a54b0c1). Which bundle gets wrapped is an artifact of minification internals, so leaving the inference in place makes every Vue bundle a future coin flip. Fix: pin the Vue config's minimizer to EsbuildPlugin({ target: 'esnext' }), keeping esbuild as a pure minifier. The loader has already transpiled to es2021 and these bundles only run in the IDE's Chromium webview — packaging shape changes, language level does not.

What this PR does not fix

The ~44-second blank login view on a slow startup. That is root.vue blocking first paint on refreshAuthState() with no loading state, and it deserves its own change (render a spinner/skeleton before auth state resolves, or lengthen/re-arm the 10s assumption). With this PR the slow path stops producing an error banner, but it is still slow. Follow-up recommended.

Verification

• npm run compile -w packages/core: 0 TS errors
• Rebuilt login/webview/vue/amazonq/index.js verified free of the CJS helper
• Timeline, artifact inspection, and code trace above are from the live repro on the reporting machine (2.5.0 installed from the marketplace)

Release note

This should go out as 2.5.1. The marketplace cannot roll back, and any 2.5.0 user whose startup exceeds the 10-second load window gets the error banner on the login view. Suggested addition to the release MCM preflight: verify the login view renders, not only chat — the two are built by different webpack configs, so a chat check does not cover this.