Summary

The connect agent assumed WordPress lived at the root of the domain. This broke several connection methods for two common setups:

• WordPress core in a subdirectory (e.g., site at example.com, WP core at example.com/wordpress/): App Password authorization and XML-RPC probes 404'd because wp-admin and xmlrpc.php live under the subdirectory, not the root.
• Whole site in a subdirectory (e.g., example.com/blog/): the WordPress.com API probe failed because it passed the path as a URL segment instead of using the domain::path syntax the API expects.

The fix uses the HTTP Link header as the primary REST API discovery method, then reads the url (siteurl) and home fields from the REST API root. All other paths -- wp-admin, xmlrpc.php, WP.com API domain -- are derived from those two values instead of guessed from the user-provided URL.

This also includes detection for Jetpack sites where the JSON API module is disabled or Jetpack isn't connected, so users get a clear message and fall back to REST API + Application Password instead of going through OAuth only to hit a wall.

Test plan

Tested against real sites in both subdirectory configurations:

• WP core in subdirectory, site at root: Link header discovers REST API at root, url field reveals the real WP core path, wp-admin and xmlrpc.php resolve correctly at that path
• Whole site in subdirectory: Link header discovers REST API under the subdir, WP.com API probe uses domain::path syntax and returns site info
• Standard root install: no behavior change, url and home are the same, all paths derive as before
• Jetpack connected, JSON API module off: detects via hasConnectedOwner, shows message, falls back
• Jetpack installed but not connected: detects via hasConnectedOwner: false, shows message, falls back
• No Jetpack: /jetpack/v4/connection returns 404, falls through to self-hosted methods