Roll back compose.generated.yml when claw up fails before apply

[mostlydev]

Problem

claw up stages and rolls back .claw-runtime when compilation fails before Docker Compose is applied, but it writes compose.generated.yml directly and leaves that new artifact behind. If generated credentials changed, operators can later apply a compose file whose service token no longer matches the restored runtime manifests.

Observed on a live pod after the required cllama image was unavailable: runtime rollback restored old claw-wall tool tokens, while compose.generated.yml retained a new claw-wall token. Recreating from that compose caused authenticated managed tools to return HTTP 401 while public feeds remained healthy.

Required behavior

Treat compose.generated.yml as part of the same pre-apply transaction as .claw-runtime:

• stage/preserve the prior compose artifact before writing the new one;
• on any pre-apply failure, restore the prior artifact (or remove the new artifact when none existed);
• once Compose has been applied, preserve the generated artifact for diagnosis, matching current runtime-stage semantics;
• cover existing-file and no-existing-file rollback, successful commit, and post-apply failure behavior.

Constraints

Do not weaken missing-image fail-closed checks or expose generated credentials in logs/tests.