Ran C.2's API-DOWN branch under operator authorisation. It FAILED, exit 1, after
~10 minutes (02:22:00Z -> 02:32:08Z):

  Unable to open API: open connection timed out
  ERROR cannot connect to model config API: unable to connect to API:
        dial tcp 10.12.8.5:17070: connect: connection refused

Its help implies a direct-to-provider fallback ("Timeout before direct
destruction", -t default 5m0s) and the first version of Path C repeated that.
It does not reach the fallback -- it needs the MODEL CONFIG API to decide what to
destroy, so an unreachable API defeats it before the timeout matters. Corrected
in place rather than deleted, so the next session does not spend ten minutes
rediscovering it.

NOTHING WAS DESTROYED AND NOTHING CASCADED: the MAAS census is identical before
and after -- 10 machines, 9 Ready/owner=None, controller VM Deployed. Safe, just
useless.

Added C.2b, the manual pair, which is the D-061 coordination principle applied to
the controller -- clean up juju's view first, then MAAS's, never the reverse:
(1) juju unregister, client-side only, touches no cloud resource; (2) release the
controller VM in MAAS, identified BY TAG rather than hostname because MAAS
auto-generated hostnames do not match the ruled names. Gates on both sides: the
tag query must return exactly one machine and must not be a role node; after
release the count must be unchanged and the tag must survive, since the tag is
what C.6/C.7 bootstrap against.

Controller VM measured for the record: subtle-grouse, system_id arfr7p, Deployed,
owner juju-vr1-dc0, tags [virtual, juju-controller-vr1-dc0].

C.2b step (2) is a gated mutation and has NOT been run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf