Steps to replicate the issue (include links if applicable):

• Not currently reproducible ? the server-side cause was fixed in T426751
• Historically: open VisualEditor on a wiki with hCaptcha active, trigger AbuseFilter, and have the save request hit a pod serving FancyCaptcha instead of hCaptcha

What happens?:

When the server returns a FancyCaptcha challenge, CaptchaSaveErrorHandler does not destroy the existing hCaptcha widget first.

What should have happened instead?:

The hCaptcha widget should be destroyed before the FancyCaptcha challenge is rendered.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Follow-up defensive fix for T426751.