Archive and Wake are each one conditional write that acts only when it moved the repository, and a Wake asked during an Archive's stop starts production after that stop #45

Problem. Archive and Wake were not atomic. Two Archives from the same view both stopped the app and both wrote an archived event. A Wake during a slow Archive stop did not start the app: the stop aborted the deploy that the Wake reused. The result was an awake repository with production down.

Root cause. updateRepoSettings wrote archived_at without a condition. It found the transition by a comparison with the repo it read before. The stop and the reconcile were not in order with each other.

Fix.

• moveArchived in core/repos.ts is one conditional UPDATE ... WHERE archived_at IS NULL (or IS NOT NULL). It returns true only when one row changed. The action stops or reconciles only then, and writes archived in the event only then.
• The core updateRepoSettings takes Omit<RepoSettings, "archived">, so it cannot write archived_at.
• Each repository's transitions take one turn after another. A Wake that comes during an Archive's stop starts production after that stop.

Test. test/apps-archive-race.test.ts (real apps runtime). A Wake during an Archive's stop (a redeploy is in flight) leaves production running. Two Archives from one stale view give one archived event. On main: both fail (production failed; 2 events). With the fix: both pass. archive-web, crew and guests tests use a setArchivedIn helper on moveArchived.

Validate (fast). Result: flaky, no new failure. contain.test.ts is baseline (box DNS). tui-sentinel.test.ts failed one time in the full run. It passes alone on this branch and is not red on main. tsc passes.