verify destroy-model blast radius before the mutation; DROP --destroy-storage ...

Operator: "We have had issues previously when a destroy has had a larger blast
radius then intended." Well-founded -- the 2026-07-21 MAAS pod delete cascaded
to its linked machine records. Measured on the live controller, not reasoned.

FINDING A: I proposed a DESTRUCTIVE flag that does nothing here. juju storage -m
vr1-dc0 returns 'No storage to display' -- zero juju-managed storage instances,
so --destroy-storage destroys nothing. ceph-osd's osd-devices are raw block
devices set by charm config, not juju storage, which is why the list is empty;
MAAS re-partitions them at re-image. Flag DROPPED.

FINDING B: no cross-model blast radius. juju offers -m vr1-dc0 is empty, so no
other model consumes a relation from it. destroy-model's own summary scopes it to
a NON-CONTROLLER model. --no-prompt verified to exist; the help's Details prose
still says -y and is stale.

FINDING C: enable_disk_erasing_on_release=false, so releasing the nine nodes
triggers no erase cycle -- they return to Ready and are re-imaged by the redeploy.

Measured correction: on the dc0 region VM the MAAS profile is 'dc0', NOT
'vr1-dc0-region'. Profile names are per-host.

Verified command: juju destroy-model vr1-dc0 --force --no-prompt
Not passed: --destroy-storage/--release-storage (no-ops), --no-wait (rushes
steps), --timeout (with --force it abandons clean shutdown).

Post-checks recorded, including the cascade signature to stop on: any DROP in the
MAAS machine count.

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