v0.4.2 — manual relocate pins the location instead of being reverted

omarchy-prayer relocate with manual coordinates now works. Until this release it did not: the command wrote your coordinates and then immediately re-detected by IP and overwrote them, inside the same invocation, exiting 0.

The bug

omarchy-prayer relocate --lat 37.4419 --lon -122.1430 --city "Palo Alto" --country US
grep city ~/.config/omarchy-prayer/config.toml
#   city = "San Diego"      ← not what you asked for

relocate writes the config, then hands off to the scheduler. With the default auto_update = true, the scheduler re-detects location by IP, sees the new coordinates are more than 50 km from what the IP says, and "corrects" them. Nothing distinguished a location you had just set on purpose from stale auto-detected data. The only visible clue read like normal operation:

omarchy-prayer: auto-relocated Palo Alto, US → San Diego, US (Δ 694 km)

The timezone cross-check did not help. It compares countries, so an IP result several hundred kilometres wrong inside one country passes straight through — and IP geolocation genuinely is that wrong sometimes. On the reporter's connection two providers disagreed by hundreds of kilometres.

The fix

A manual override now pins your location: it also sets auto_update = false, and tells you so.

omarchy-prayer: location set to Palo Alto, US (37.4419, -122.1430)
  pinned: auto-update disabled so this location sticks (re-enable with `omarchy-prayer relocate --auto`)

• omarchy-prayer relocate — one-shot IP re-detect, leaves the setting alone
• omarchy-prayer relocate --lat … --lon … --city … --country … — pins
• omarchy-prayer relocate --auto — resumes automatic tracking

Passing --auto together with manual coordinates is now refused rather than doing both.

Also fixed

The confirmation line was lost through a pipe. exec replaces the process without flushing stdout, so omarchy-prayer relocate … | cat printed nothing while the contradictory stderr line still showed — which made the first bug harder to diagnose.

A commented section header could break your config. [location] # my home is valid TOML but the config writer did not recognise it, so writing a key appended a second [location] table and the file stopped parsing — taking every command down until repaired by hand. Both the reader and the writer accept it now.

---

Thanks to whoever filed the report — the reproduction, the root-cause trace, and the option analysis were all accurate, including the detail that suppressing auto-relocate for one run would not have been enough on its own.

329 tests, green under both invocations. The widget is unchanged; the plugin stays at 0.4.0.