feat: install-theme installs from WordPress.org, not activated (#350)

[ifahimreza]

Closes #350

Stacked on #355 (base feat/349-install-plugin). Merge #353, #354, #355, then this, with merge commits.

What

A new tool, saddle/install-theme. It installs one theme from the WordPress.org directory, by slug, through WordPress's own installer in the background, after a confirmed preview. The theme is never activated; activate-theme stays its own step.

Why

The second half of #347's installs, with the same hard line as install-plugin.

How

• Same shape as install-plugin:
  • a fresh themes_api() answer
  • a preview: version, installs, rating, last update, the WordPress and PHP it needs, and its parent theme if it is a child
  • a token bound to the version
  • a background run through Theme_Upgrader::install()
  • capabilities: switch_themes to call the tool, install_themes checked in the handler after any blocked_by() reason
  • the same refusals, including a package outside downloads.wordpress.org/theme/
• Child themes. Core's theme installer fetches and installs a missing parent on its own (Theme_Upgrader::check_parent_theme_filter()), which nobody previewed. Three layers stop that:
  1. A child theme whose parent is not installed is refused before any token, naming the parent to install first.
  2. The run checks again, including that the parent's folder still exists. WP_Theme can answer from the object cache for up to 30 minutes after a delete; a test caught this.
  3. During the run, a one-shot themes_api filter answers only the confirmed slug. A test proves it: with the guard removed, the test fails because core asks WordPress.org for the parent.
• Restructure. Saddle_Directory now only talks to the API (242 lines). The installed check and the refusals moved to Saddle_Install_Runner (253 lines), where both the run and the abilities reach them, as blocked_by() sits on the update runner. install_plugin and install_theme share one install( $type, $input ) (the class is 289 lines).
• A fix found end to end: themes_api() was undefined in a real REST request. The update runner loads the admin theme.php keyed on wp_get_themes(), which wp-includes always defines. The suite loads admin files up front, which hid it. Saddle_Directory::load_api() now keys on themes_api. The update path is unchanged.
• Copy. The context line, the undo reason and the readme now say plugins and themes. update-theme's description, External services item 7, and a 1.5.2 changelog line. The .pot is regenerated.

Testing

• phpunit on PHP 8.2: 1490 tests, 8342 assertions, 1 skipped (the existing 11-plugin test).
• phpcs on every changed PHP file: clean.
• tests/installs-test.php: 10 theme tests, with fixtures recorded from the live themes API (Twenty Twenty-Five, and the real child theme legacy-kindergarten-child, which pins that WordPress.org names the parent in template and parent):
  • the tier test, and a preview that changes nothing
  • a confirm with zero upgrader calls, and single-use tokens
  • the version bind
  • a real install through Theme_Upgrader that never switches the theme
  • the child-theme refusal, the parent removed before the run, and the guard
  • the remaining refusals and the capability check
• Real install, end to end (Playground CLI, built wporg zip, WordPress 7.1.3, PHP 8.2, Saddle key at Manage the site, small MCP client):
  • install-theme legacy-kindergarten-child was refused, naming its missing parent.
  • install-theme twentytwentytwo: preview, then confirm, then a page load ran cron. The result was installed, and list-themes shows Twenty Twenty-Two 2.2 with active: false while Twenty Twenty-Five stays active.
  • The plugin path was rerun on this build: classic-editor installed, inactive.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}