EXTENSIONS

A declared fleet of base OCI images we keep security-patched. The whole job — what to patch (`source` = registry/repository/tag), how (`patch`, default: apply all pending security updates), where to publish (`destination` = repository/tag under a run-time `registry`), and what to assert (`expect`, optional version floor) — lives in the model instance's `globalArguments.images`, so a single `swamp model method run <instance> patch --input registry=<registry[/namespace]>` builds, verifies, and pushes every image. The destination registry is the `registry` arg (or `globalArguments.registry`), so one instance retargets to a different registry per run. No workflow. Verify is foreknowledge-free (asserts no security updates remain pending on every platform), which fits a scheduled cadence; an optional per-image `expect` adds a version floor. Composes the pure logic of @hivemq/oci/image/patch and the buildx wrapper of @hivemq/docker; it is the only one of the three that drives buildx. Motivated by PLT-941 (openssl CVE-2026-45447): own the patch cadence instead of waiting on upstream base rebuilds.

Take a single base OCI image identifier and emit its security-patched counterpart under the HiveMQ naming convention (<registry>/<namespace>/<flattened>:<tag>-hivemq-patched-<date>). A pure logic model (`plan` generates the security-upgrade Dockerfile + derives the re-homed target; `verify` asserts the expected fixed package versions) plus a bundled workflow that orchestrates a container CLI wrapper around it: plan, build the multi-arch image, verify the expected versions on every platform of it, then push. Two workflow variants ship: the Apple @hivemq/container engine (self-hosted macOS) and @hivemq/docker (standard Linux/GitHub-hosted runners). Motivated by PLT-941 (openssl CVE-2026-45447): own the patch cadence instead of waiting on upstream base rebuilds. Registry credentials are injected from a swamp vault at run time and never persisted in a committed instance.