Scheduling: publish binaries and an installer, or keep the README honest

[jeremi]

What

Registry Scheduling ships a container image but no released binary and no
installer, while crates/registry-scheduling/install.sh exists in the tree
and the other runtimes all publish one.

release/scripts/release_candidate.py gates each product's payloads behind a
minimum version, for example BREG_RELEASE_MINIMUM_VERSION and
CASEWORK_RELEASE_MINIMUM_VERSION, each adding three platform binaries plus
the versioned and unversioned installer. Scheduling has no such block. The
container image roster is wired (SCHEDULING_RUNTIME_IMAGE_NAMES), so the
image half of the story is already true.

Because _relay_v2_payload_inventory is compared for exact equality, adding
the assets to a release manifest without extending the inventory first is
refused as unexpected payloads.

Why it is filed rather than fixed

The README in #1092 advertised scheduling-install.sh and a
SCHEDULING_INSTALL_DIR override that no release would produce. That PR now
states what is true today instead. Wiring the artifacts through the release
pipeline touches release provenance, which is security-sensitive and wants its
own reviewed change rather than being folded into a 173-file feature PR.

Done when

• release_candidate.py carries a scheduling minimum-version block adding the
  platform binaries and both installer names.
• The release workflow builds, checksums, and uploads them on the same terms as
  the sibling runtimes.
• README.md names the installer again, and SCHEDULING_INSTALL_DIR returns to
  the override list.
• release/scripts/test_registry_release.py covers the new inventory entries.