fix: stop tests leaking sensitive values into one another

[josegonzalez]

Four property tests register a secret and never clear it, so it stays registered for every test that runs afterwards and any of them reading that literal back would see *** instead. Nothing fails today, because no test happens to assert on token123 or deploy-bot - but the exposure is one unlucky fixture value away, and it becomes a real hazard the moment tests run in parallel and the set of tests that ran first stops being fixed.

Production code is the source and is behaving correctly: planProperty registers a sensitive property's desired and probed values so a drift reason cannot echo a credential, and nothing in tasks clears the registry afterwards because a CLI process exits. The four tests that reach that path now take an empty registry and put the previous set back when they finish, through a shared isolateMaskRegistry helper, and the seven tests that were already managing the registry by hand use the same helper instead of clearing to nil.

Restoring rather than clearing is what makes the leak observable at all. Clearing is why it went unnoticed: the tests that set the registry directly wiped it on the way out, so residue never survived far enough to be seen - an end-of-run check came back clean until those cleanups stopped wiping. With nothing wiping, TestMain can assert the registry is empty when the package finishes and fail the run when it is not, which is what pins this rather than leaving it to be rediscovered.

Integration tests register through the same production path, and there the registration is the behaviour under test rather than a leak - the documented dokku_letsencrypt_property example sets a dns-provider-* credential. They are isolated at skipIfNoDokkuT, the one gate all 139 of them already pass through, so none has to know whether the task it applies happens to be sensitive.

commands needs none of it: every command clears the registry on the way out of Run, so residue cannot accumulate there.

Also saves and restores color.NoColor in the fmt colour test rather than assuming the previous value was true, matching TestFormatterColorOnEmitsAnsi.

Prerequisite for #502.