Make the script resumable / idempotent across stages

[ALERTua]

Reported by @Eagle3386 in #1: the script had to be modified locally "to allow for continuing instead of running it all again".

Right now any failure in the middle of the run (BitLocker, formatting, Dev Drive trust) aborts everything, and re-running starts from partition creation. On a machine where a step legitimately fails, that means repeating destructive work.

To do:

• make each stage idempotent: detect that the partition/volume/BitLocker protector already exists and skip instead of recreating
• allow the run to be resumed from the stage that failed
• decide whether this needs an explicit switch or should just be the default behaviour

[ALERTua]

@Eagle3386 I looked into this properly before answering, and I am closing it — but with an
alternative that should cover what actually went wrong for you. Explanation, because the reasoning
matters more than the verdict.

One stage can never be resumed. The Dev Drive designation is applied at format time and nowhere
else: Microsoft's documentation states that existing volumes cannot be converted, and that
reformatting one destroys what is on it. So "continue past a failed format" can only mean "delete the
partition and make it again". That is a destructive act, and no amount of code makes it safe to do
on the strength of a guess.

One stage cannot even be detected. After a volume is shrunk, Windows keeps no trace that a shrink
happened. A resume would have to trust a state file written before the fact, and a state file can be
stale, can survive changes made by hand, and can point at a disk number — which Microsoft documents
as not stable across restarts.

And the general case has to guess which volume it is looking at. Before a run the target is a
disk number and a size; after a failed one it is a volume with a letter. Bridging those means the
script picking a partition on its own and then repartitioning or reformatting it. A leftover
unrecognised partition might be the one it made — or a Linux partition, or someone else's encrypted
volume. Getting that wrong on a tool that repartitions disks is not an acceptable failure mode.

What is worth building instead. Reading the code carefully, everything after the volume is
formatted depends on one thing: the drive letter. Not the mode, not the disk, not the size. So the
part of the script where runs actually fail — BitLocker, deduplication — can be re-run against a
drive that already exists, and the user names the drive, so nothing has to be guessed.

That is #34. It covers your case directly: you got past volume creation and got stuck on BitLocker,
and what you wanted was to retry the rest rather than start over. Please say if that reading is wrong
— you are the one who hit this, and if the narrow version would not have helped you, I would rather
know before it is built.

Two defects turned up while working this out, both real today and independent of any resume feature:
re-running in shrink mode shrinks the drive a second time (#32), and adding BitLocker protectors
twice produces two recovery keys and breaks the Azure AD backup (#33). Both are being fixed.

Closing in favour of #34.

[Eagle3386]

You guessed right, your very welcomed explanation helped understand the reasoning & I'm perfectly fine with the outcome!
Thanks so much, Alexey! 👏🏻❤️