v1.2.1 - fix: overwrite was discarded for wordpress.org slug installs

The bug

ans_ops_route_install() called:

ans_ops_run_install( $package, ( '' !== $slug ) ? false : $overwrite );

That threw away the caller's overwrite flag whenever the source was a
WordPress.org slug - including when /plugin/update had just set it to
true.

Consequence:

Source	Already installed?	Before 1.2.1
slug (wordpress.org)	no	works
slug	yes	always HTTP 500
url / zip_b64 / drive_file_id + overwrite	yes	works

So new installs worked, our own GitHub-released plugins updated fine, and
updating any already-installed wordpress.org plugin (WooCommerce, Yoast,
Kadence, Tickera add-ons) was impossible. That mix is why the failure read as
intermittent rather than total.

1.2.1 honours $overwrite for every source.

This retires gotcha 17 in the Plugin Build Registry - the
deactivate/delete/reinstall workaround is no longer needed, and it was only
ever safe for plugins holding no options.

Also: failures now say why

A failed install returned { ok:false, error, messages } with HTTP 500. The
MCP connector's error mapper reads only the WordPress WP_Error shape
(code / message), so it matched neither field and reported a bare
WordPress API returned HTTP 500. - discarding a reason the server had
already spelled out.

Failure responses now carry code and message as well as error and
messages, so the existing connector surfaces the real cause with no
redeploy.