CreaCaptcha

lostpassword_post is NOT a form hook. WordPress core fires it inside retrieve_password() (wp-includes/user.php), and that function is also the back end of every administrative and programmatic reset: wp_ajax_send_password_reset() behind the "Send reset link" button on user-edit.php, the "Send password reset" bulk action in wp-admin/users.php, and any WP-CLI or third-party plugin call. None of those ever renders our widget, so demanding a solved challenge there rejected the request with "Die Sicherheitsabfrage wurde nicht bestanden" and no mail was ever sent — retrieve_password() bails out before dispatch once $errors is non-empty.

Returns the reason rather than a bare bool for two reasons: the caller logs it on the verified event exactly like a bypass reason, and every branch stays individually observable in the regression test. Under the CLI SAPI a bool predicate could only ever show its CLI branch — which is why the administrative branch is checked FIRST here, before the non-interactive ones. In production the order is immaterial: WP-CLI has neither is_admin() nor a current user, so it can never take the administrative branch.