Document that retiring a workflow unbinds it from state

Verified by driving the installed console script against a live instance:
`destroy` (retire tier) drops the state binding, so a subsequent `apply` of
the same source creates a second workflow rather than reclaiming the retired
one, leaving two same-named workflows with one inert.

That follows from the state file being the identity link and is the correct
behaviour for a command called destroy, but it surprises people. Document it,
and point at the alternative -- set active=False in source and apply -- for
the "turn this off for now" case, which keeps the binding intact.

Author: SAKMZ

README.md

@@ -174,6 +174,12 @@ So `destroy` has two tiers: the default *retires* a workflow (deactivates it and
 your state file, leaving it inert on the instance), and `--hard` deletes it, which is
 irreversible and cascades to execution history.
 
+Retiring unbinds identity, so **a later `apply` of the same source creates a second workflow
+rather than reclaiming the retired one.** You end up with two same-named workflows, one inert.
+That follows from the state file being the identity link, but it surprises people. If you meant
+"turn this off for now", set `active=False` in your source and `apply` — that keeps the binding.
+Use `destroy` when you mean it.
+
 ## Determinism
 
 Compiling the same source twice produces **byte-identical** JSON, on any machine, under any