Add sd21 to the residency contract

[TroyHernandez]

The sixth resident family. Stacked on #62 — based on feat/sdxl-resident,
because it uses the generic pieces that PR introduces (.resident_gpu_set(),
.devices_for_pipeline(), the "cuda:N" dtype fix, the allocator pre-warm).
Retarget to main before #62 merges.

With that machinery already in place this is a loader shim, two switch
branches and one entry in .resident_families.

Verified end to end at 512x512: load 14.0 s (4.678 GB pinned), activate
0.54 s, real image, same seed reproducing after a full GPU round trip,
reserved.peak 6.807 GB. Comfortable on a 12 GB card. Suite 1197
assertions, 0 failures.

Two places SD 2.1 disagrees with SDXL

The UNet is float32, not float16, and this is a trap rather than a
preference. SD 2.1's attention overflows in float16 and the pipeline
returns all-NaN instead of raising, so a float16 resident would load,
activate, generate and hand back a blank image with nothing anywhere to
catch it. txt2img_sd21()'s native path already defaults to float32 for
this reason; the resident loader has to make the same call independently,
because it fixes the dtype before the weights are pinned and nothing
downstream can undo it. Note setup_dtype() answers float16 for a CUDA
device, so sd21_load_pipeline() deliberately does not delegate to it.

The device list is keyed by get_required_components() rather than by
the pipeline's own fields. SD 2.1 requires an encoder — the VAE encoder
img2img needs — that the text-to-image pipeline never builds, and
standardize_devices() refuses a list without it. It follows the decoder,
which is where it would live anyway. This also changes the sdxl injection,
which now supplies its encoder explicitly instead of relying on
standardize_devices()'s fill-in; the sdxl end-to-end was re-run
unchanged afterwards (18/18, identical numbers).

Why gpu_components = "unet", for a different reason than SDXL

SDXL is undone by its float32 VAE decode. SD 2.1 never reaches the decode:
the float32 requirement makes the denoise itself expensive. At the 768x768
default it wants 11.35 GB allocated plus 3.1 GB of allocator slack, which
loses on a 15.47 GiB card.

That is not a residency artifact, and I checked rather than assumed — a
plain txt2img_sd21() with the same devices and dtype OOMs at 11.494 GB,
within 0.04 GB of the resident run. The pre-warm and the bulk onload are
both exonerated. auto_devices() already answers "unet on cuda, the rest
on cpu" for this model at every strategy, so residency is agreeing with the
package rather than inventing a placement.

Moving the encoders off the card saves only 0.11 GB at 768, because the
peak is denoise activations rather than weights. Resolution is what decides
it:

resolution	allocated.peak	allocator slack	result
512x512	6.807 GB	0.011 GB	passes
768x768	11.35 GB	3.13 GB	OOM on 15.47 GiB

A pre-existing issue this surfaced

SD 2.1's native float32 path does not fit its own default resolution on a
16 GB card, with or without residency. That wants its own fix — the
expandable_segments:True the allocator itself suggests is the obvious
lever, and diffuseR already uses it on other paths. It is recorded in NEWS
rather than papered over by quietly lowering a default, since changing
img_dim's default is a user-visible decision and not mine to make inside
a residency PR.