Reinstall over an existing Omarchy in its own space

[joshuaswarren]

This PR lets someone who already has Omarchy on their Mac reinstall it over itself, instead of removing it and installing again. It reverses part of b1dade4 ("the installer never replaces an existing Omarchy"), so it needs the owner's call. @maralcbr, do you want this? The other half of b1dade4 stays: two or more installs still get the refusal.

The reason is time on a big disk. Today a reinstall means Remove Omarchy, which grows macOS back, and then a new install, which shrinks macOS by the same amount. On a 14-inch M2 Max with a 4 TB disk, that shrink is one diskutil apfs resizeContainer call. It took 2,740 s on 2026-10-06 and 5,002 s on 2026-09-18, both for the same 255,999,344,640 bytes. The engine's replace path deletes the old stub and erases the four partitions instead. That took about 14 s on the same Mac.

What changes:

• On the refusal page, a Mac with exactly one found install now gets Reinstall Omarchy. It plans the engine's existing replace candidate, so the new install reuses the old install's space and macOS is not resized.
• InstallerAllocationRecommendation(replacing:in:) picks the replace candidate at its exact length. preparePlan takes replacing:; without it an existing install is refused as before.
• The session offers reinstallOverExisting() only for exactly one found install, and forgets the choice on the next inspection.
• The plan page shows macOS at its current size and asks to approve the layout, not a resize.
• The engine is unchanged.

The second commit is part of this PR, and it must ship with the first. Removal sets macOS as the startup disk before it deletes anything (eed259e), but the engine's remove_existing_install does not. Without the second commit, a reinstall started from macOS while Omarchy is still the startup disk would erase that Omarchy, and a failure after the erase would leave the Mac pointed at a volume that no longer boots. The helper now runs the same step before a replace install starts the engine. If bless refuses, or macOS does not confirm the change, the helper throws ClosedEngineHelperError.macOSStartupNotSet and nothing is erased. A fresh install never touches the startup disk. One thing I did not check: whether the new install sets Omarchy as the startup disk again at the end. If it does not, someone who wants Omarchy as the default sets it once in Startup Disk settings.

Tests: testReplacingPlansTheExistingInstallsExactExtent, testReinstallPlansTheReplaceOfTheOneExistingInstall, testReinstallIsUnavailableUnlessExactlyOneInstallWasFound and testAReplaceMakesMacOSTheStartupDiskBeforeTheEngineRuns (five cases). On main, the first three do not compile, because the reinstall API does not exist. With only the three-line call in submit removed, three of the five startup-disk cases fail, because the engine ran while the startup disk was still Omarchy. The existing refusal tests and the 64 OmarchyRemovalTests still pass.

Checked at b41100a, rebased on main 27bdf16 (no new commits upstream), on a Mac Studio with macOS 26.6.2, Xcode 27.0 and Swift 6.4:

• swift-format lint --strict: exit 0.
• Debug swift test: exit 0 (UXCore 149, Lifecycle 3, TrustCore 521 with the 1 existing skip, App 8).
• Release swift test: exit 0 (138, 3, 521, 5).
• ./test/all: exit 0.

Not done: no replace install has run on hardware, and there is no screenshot of the new refusal page. The engine's REPLACE_STAGES (remove_existing_install, journaled existing-install-removed) ship today but have not run from this app. The replace erases the old install's four partitions and its stub, so plan review, approval and the owner's password still come first, and only exactly one found install unlocks the button.

To revert, revert both commits. The app goes back to the b1dade4 refusal, and the engine is unchanged, so nothing on disk depends on the app change.