ABI-2 image isolation for the 3.0 transition
============================================

The unchanged server line must keep consuming ABI 2 while libdrizzle 3.0 is
prepared. The server ``Containerfile`` defaults ``LIBDRIZZLE_IMAGE`` and
``WIREDTIGER_IMAGE`` to the respective ``quay.io/drizzle`` repositories'
``abi2-testing-slim`` channels. The WiredTiger build and runtime stages also
use the libdrizzle ABI-2 channel, and its build/upload/promote jobs publish
the WiredTiger ABI-2 tag.

These tags follow compatible C++ builds until the 3.0 cutover. Before either
image is built against ABI 3, remove its ABI-2 publication tag from the job
configuration. Leave the last ABI-2 tags pointing to their existing images
so unchanged consumers and rollback builds retain a served manifest.
Do not retarget these channels to ABI 3.

A digest identifies content but does not retain it in Quay. Moving every tag
off a manifest can make its digest unavailable; a build must not depend on an
old digest whose tags have all moved. For an exact reproducible rollback,
first publish and retain a distinct snapshot tag, verify its manifest and
platforms, and then record that tag and digest together.

The server consumes libdrizzle directly and copies ``/usr/local`` from the
WiredTiger payload image. A paired 3.0 candidate can override
``LIBDRIZZLE_IMAGE`` with its actual speculative image reference. Override
``WIREDTIGER_IMAGE`` as well when testing a rebuilt payload. Pass the same
libdrizzle candidate to both WiredTiger stages when rebuilding it. Ensure
candidate publication no longer includes the ABI-2 tags before using those
overrides for a 3.0 build.

The images inspected for this transition provide ``linux/amd64``. The ABI-2
channel names do not imply multi-architecture support: publish and verify
arm64-compatible inputs before an arm64 3.0 promotion. Validate downstream
builds and rollback inputs in Zuul before the packaging switch.