feat: update-core applies the release WordPress offers (#351)

[ifahimreza]

Closes #351

Stacked on #356 (base feat/350-install-theme). Merge #353 → #354 → #355 → #356 → this, with merge commits.

What

A new tool, saddle/update-core. It updates WordPress itself to a release WordPress already offers for background updates, through core's own automatic updater in the background runner, after a confirmed preview.

Why

#347: core updates join plugin and theme updates. Fahim's decision (2026-10-12): minor and security releases always. A major only behind WordPress's own "automatic updates for all new versions" switch, which no tool can flip.

⚠️ One thing Fahim should know

Since WordPress 5.6, a new install defaults that switch to on (auto_update_core_major = enabled in schema.php). Sites upgraded from before 5.6 have unset, and an owner who picked "maintenance and security releases only" has disabled; both mean minor only.

So on most modern sites, update-core will apply a major release when asked. This is exactly what WordPress would do by itself within about 12 hours. Saddle just does it now, after a confirmed preview. It is refused only where the owner (or an old install) has majors off.

That matches the rule you chose. Your expectation may have been that majors are usually refused, so I changed the copy to say "when WordPress is set to update itself to all new versions" rather than "when the owner turned it on", and a test pins core's default. If you want majors to need a separate Saddle opt-in instead, that's a small change. Say so.

How

• Offers. Saddle reads the autoupdate entries of the update_core transient: the releases WordPress would apply in the background. get_core_updates() leaves those out; find_core_auto_update() reads the same. It picks the newest minor release, else a major only if Core_Upgrader::should_update_to_version() says WordPress would apply it itself (the switch, WP_AUTO_UPDATE_CORE, allow_major_auto_core_updates). When both are offered, the minor comes first.
• Refused before any token:
  • blocked_by('core') (context ABSPATH)
  • no update_core
  • a development version
  • a recorded critical auto_core_update_failed
  • PHP or MySQL below the offer's needs (MySQL is skipped on SQLite, as core does)
  • a major WordPress would not apply
  • nothing offered
• Preview. From and to, minor or major, the locale, and the PHP and MySQL needed against this site's. For a major: the active plugins WordPress.org says are not tested with the new X.Y, plus three plain sentences on what can't be undone (no rollback, database upgrade, Saddle relies on core APIs). The token binds release and locale.
• Run. A one-shot auto_update_core filter says yes for exactly the confirmed version, and WP_Automatic_Updater::update( 'core', … ) applies it.
• The runner split. Saddle_Update_Runner had reached 461 lines. The offer path (offers, the one-shot filter, the apply loop, result recording) moved to Saddle_Offer_Runner (180 lines), beside Saddle_Install_Runner. Saddle_Update_Runner keeps scheduling, guards, the lock and the run store (304 lines), and its public API is unchanged. The offer path also closes the output buffer core's skin opens on a failure (WP_Upgrader_Skin::error() calls header()).
• Copy. A context refusal line, an undo reason (no rollback for core), CLAUDE.md and ROADMAP wording, the readme Updates and Undo bullets, a 1.5.2 changelog line, and the .pot.

Testing

• phpunit on PHP 8.2: 1503 tests, 8570 assertions, 1 skipped (the existing 11-plugin test).
• phpcs on every changed PHP file: clean.
• New tests/core-updates-test.php (13 tests). Offers are built on a version-check answer recorded live, which pins the field names. Covered:
  • the tier test, and a minor preview that changes nothing
  • a confirm with zero upgrader calls, and single-use tokens
  • a token for one release failing for another
  • minor before major
  • core's new-install default pinned, a major refused when WordPress is minor-only, and a major allowed with untested plugins listed
  • every refusal
  • the runner handing exactly the confirmed package to core (download refused in the test, WordPress unchanged, maintenance off), and a release no longer offered reported up_to_date
• A real core update, end to end. A disposable Playground was pinned to WordPress 7.1.2, with the built wporg zip and a Saddle key at Manage the site, driven by a small MCP client:
  1. list-updates offered 7.1.3.
  2. The update-core preview said minor, 7.1.2 to 7.1.3.
  3. Confirming queued the run, and one page load ran cron.
  4. The run finished applied, and get-site-info reports 7.1.3.
  5. The front page returns 200.
  6. The log reads "Updated WordPress from 7.1.2 to 7.1.3."

🤖 Generated with Claude Code

---

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