fix(mpc): keep the newest replan

[frahlg]

Summary

• Give every replan request a monotonic generation.
• Snapshot mode, params, battery fleet and reason when the request starts.
• Publish plan state, shadow state and diagnostics only when the request is still newest.
• Return the active plan to a superseded caller instead of its unpublished local result.
• Keep lastReason under the service lock and interpret each active slot with the mode that produced its plan.

Root cause

Replans can run at the same time. A slow older solve could finish after a newer mode change or reactive trigger and replace the newer plan. The trigger reason could also drift from the plan, and some lastReason writes were outside the mutex.

The regression test blocks the first self-consumption solve, completes a newer arbitrage solve, then releases the old solve. It checks the active plan, mode, reason, generation, diagnosis and persisted diagnostic.

Tests on current master f9297c0

• go test -race -count=1 ./internal/mpc
• go test -race -count=1 ./internal/api ./cmd/ftw
• latest-wins race regression repeated 20 times
• make verify-all
  • 117 Python tests
  • all Go packages and full-stack e2e
  • Core↔Optimizer multi-device contract
  • compose migration, vet and build
  • linux/arm64, linux/amd64 and windows/amd64 cross-builds
• independent review against the updated head found no P0–P3 issue

Scope

This prevents stale publication. #893 now bounds the queue and active solver budget. Cancellation of superseded Core replans remains a small follow-up: an older solve may still consume work until its context or solver deadline ends, but it cannot publish over this request.

Refs #885