feat(api): explicit distributed-backend selection (MDLABackend / IGGBackend), mirroring AbstractJVPBackend

Start with src/operators/linearize.jl to follow the existing explicit-backend pattern, then inspect the distributed entry point in ext/MatrixFreeOperatorsMDLAExt.jl and DESIGN.md §10.4. Review the relationship with #46 and the existing distributed tests. Done means the core tags and fallback, the MDLA implementation, unloaded-backend error test, documentation distinction from KernelAbstractions devices, and the IGG integration are all covered.

Problem

There is no way to choose a distributed backend. prepare_distributed is exported from the core, but its only method is defined inside ext/MatrixFreeOperatorsMDLAExt.jl:

function prepare_distributed(L0::AbstractOperator, nparts::Integer; devices=nothing)

So today the backend is whatever extension happens to be loaded, selected implicitly. Two consequences:

1. Calling it without MDLA loaded gives a bare MethodError on an exported symbol, with no hint that the fix is using MultiDeviceLinearAlgebra.
2. It does not survive a second backend. Once the IGG halo lands (#46), two extensions would define competing methods with the same (operator, integer) signature. That is an ambiguity, and disambiguating it by keyword is worse.

Selection should be explicit and declarative, the way choosing an AD backend or a KernelAbstractions device is.

Proposal — mirror AbstractJVPBackend

We already have exactly this pattern in-repo, and it should be the model rather than inventing a second convention. src/operators/linearize.jl defines the abstract type and both concrete tags in the core, exports them, and lets the extension implement the behaviour:

abstract type AbstractJVPBackend end
struct FiniteDifferenceJVP <: AbstractJVPBackend end
struct EnzymeJVP           <: AbstractJVPBackend end   # core-defined; Enzyme ext implements

Its docstring already states the principle we want here — "Selecting the backend is deliberately explicit rather than ambient: the backends differ in ... which operations they support, so which one you get must not depend on load order." That reasoning applies verbatim to MDLA vs IGG.

This is also the ADTypes/DifferentiationInterface model the request pointed at: AutoEnzyme() lives in ADTypes, not in Enzyme, so you can name and dispatch on a backend you have not loaded.

Sketch:

# core
abstract type AbstractDistributedBackend end

struct MDLABackend <: AbstractDistributedBackend    # single-node multi-GPU, slab decomposition
    nparts::Int
    devices::Union{Nothing,Vector{Int}}
end

struct IGGBackend <: AbstractDistributedBackend     # multi-node MPI, 3D blocking
    dims::NTuple{3,Int}
    periodic::NTuple{3,Bool}
end

prepare_distributed(L, backend::AbstractDistributedBackend; kwargs...)

with a core fallback whose whole job is a good error:

prepare_distributed(::AbstractOperator, b::AbstractDistributedBackend; kwargs...) =
    error("no distributed method for $(nameof(typeof(b))) — load the backing package (e.g. `using MultiDeviceLinearAlgebra`)")

Extensions then implement prepare_distributed(L, ::MDLABackend) / (L, ::IGGBackend) against the existing _dist_scatter! / _dist_reduce! seam. Nothing about the seam itself changes.

Constraints

• Tags must be config-only and free of backend types. An MDLABackend holding a PartitionSpec, or an IGGBackend holding an MPI communicator, would drag the dependency into the core and defeat the point. Ints, tuples, symbols only.
• This is orthogonal to the KernelAbstractions device, and the docs must say so explicitly — the analogy that motivates the API is also the easiest thing for a reader to conflate. The KA backend answers which device runs the kernel; this answers how partitions talk to each other. A real run picks both (CUDABackend() device + IGGBackend() distribution), and CartesianGrid's Dev parameter is the former, not the latter.
• Construction-time only. Like EnzymeJVP, the tag selects behaviour when the prepared operator is built and must not leak into the operator tree or the mul! hot path.
• Does not change prepare's contract — still stateful and single-threaded, one per concurrent solve.

Decisions to make while implementing

• Whether the existing prepare_distributed(L, nparts::Integer; devices) stays as a deprecated shim forwarding to MDLABackend(nparts; devices), or goes away outright. It is unregistered and pre-v1, so removing it is defensible; a shim is cheap.
• Whether AbstractJVPBackend and AbstractDistributedBackend get documented together as one "explicit backend selection" concept in the docs, since they now share a rationale. Recommend yes — one section, two axes.
• Whether a trivial SerialBackend() is worth having so single-rank code paths are expressible without nothing.

Done when

• AbstractDistributedBackend + MDLABackend + IGGBackend defined and exported from core
• prepare_distributed(L, backend; …) is the documented entry point; core fallback errors with a "load X" message
• MDLA extension implements its tag; existing tests pass through the new entry point
• Requesting an unloaded backend is tested for the error message, not just the throw
• Docs state the KA-device vs distributed-backend distinction explicitly
• #46's IGG extension implements IGGBackend against this API rather than adding another entry point

Related: #46 (IGG halo backend), DESIGN.md §10.4.

---

_{🤖 Written by Claude — Kyle pointed at the shape, I filled in the paperwork.}