fix: serialize TaskController lifecycle ops to prevent orphaned election tasks

[Keshoid]

Problem

config elections enable/include/exclude HTTP handlers fire tokio::spawn(restart()) without serialization. TaskController::restart() is disable().await; enable().await with the inner std::sync::Mutex<State> released between phases (and dropped across handle.await). Two concurrent restarts can interleave such that a task is spawned by caller B, then its cancel/handle are overwritten by caller A's resumed enable() — orphaning B's task until process shutdown.

Fix

Add a tokio::sync::Mutex<()> (lifecycle) to TaskController. Public enable / disable / restart each acquire it first, then delegate to private _locked helpers (original bodies unchanged). restart() now holds the lock across the full disable→enable sequence, so concurrent callers queue instead of racing.

The existing std::sync::Mutex<State> is kept for short critical sections so status() stays non-blocking and isn't held back by long-running lifecycle work.

Scope (deliberately minimal)

• HTTP handlers still use detached tokio::spawn(restart()) — now safe because restarts queue on lifecycle. Switching them to await would block the HTTP response on restart duration, which is a separate UX decision.
• The "config read at spawn time" ordering note from the ticket is not addressed — harmless once atomicity is fixed.

Closes SMA-89

[linear]

SMA-89

[Copilot]

Pull request overview

This PR serializes TaskController lifecycle operations to prevent concurrent restarts from interleaving and orphaning spawned service tasks.

Changes:

• Added an async lifecycle mutex to serialize enable, disable, and restart.
• Split lifecycle operations into public locked methods and private locked helpers.
• Added a concurrent restart regression smoke test.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.