Plugin Directory: Let reviewers block a release from being served

[obenland]

Summary

Reviewers could already skip the release cooldown, but had no way to hold a release back short
of closing the whole plugin. This adds a Block control to the Controls metabox, alongside
the force-release one and sharing a single reason field, so a version still inside its cooldown
can be held out of update_source — the previously served version keeps being served — until a
reviewer force-releases it.

This is the plumbing half of #720, which is now split in two. The scan-driven half is #729.

How it works

• The hold — API_Update_Updater::block_release(), the counterpart to force_release(),
  records a release_block on the release row. A single gate in update_single_plugin()
  honours it, so both the deferred cooldown cron and the backup reconciliation cron keep the
  version out of update_source.
• Only where there's something to hold — a version that's already live can't be un-shipped.
  A block on one is refused rather than recorded as a hold that never takes effect.
• Unblock — a reviewer force-release clears the block and serves the version; the override
  is recorded in the audit log.
• Reviewer visibility — the metabox shows a blocked-state notice alongside the
  force-release control, and the Block button appears only while a version is still cooling
  down.

The sync_availability() fix

Holding a version back means update_single_plugin() can't rewrite the row at all — every
version-specific column describes the held version, not the served one.

That was already true of the release cooldown, and it means a status change never reached
sites while one was in flight: closing a plugin whose next version was deferred left
update_source serving the current version with available = 1. A block makes that unbounded
rather than a few hours, which is what surfaced it.

sync_availability() now writes the availability and closure fields on their own and leaves the
served version alone. Worth reviewing on its own terms — it fixes live behaviour that predates
this feature.

Tests

Reviewer_Release_Block_Test covers the block through the same path the metabox uses: the hold,
the audit notes, the refusals, the metabox save handler including its capability check, and
closing/re-opening a plugin while a version is held. Its fixture lives in
Release_Block_Test_Case, resolved by a small autoloader in the test bootstrap so the shared
bases don't need requiring in dependency order.

170 tests pass locally against environments/plugin-directory.

Notes for reviewers

• The test-environment fix (first commit) is byte-for-byte Plugin Directory: Serve a release immediately when Gandalf reports no findings #717's c1edf5b11. Whichever of
  Plugin Directory: Serve a release immediately when Gandalf reports no findings #717 / this / Plugin Directory: Block a release when a security scan reports a high risk score #729 lands second should drop it.
• API_Update_Updater::get_served_version() is the same helper Plugin Directory: Serve a release immediately when Gandalf reports no findings #717 extracts.
• Nothing here depends on Gandalf, or on any policy decision about scanning. Blocking is a
  manual reviewer action.

🤖 Generated with Claude Code