Keep a repeating week on its weekday when the planner picks the dates

A yearly-repeating period kept the same calendar date instead of the same
weekday: 2026-10-05..10-11 (Mon-Sun) recurred as 2027-10-05..10-11 (Tue-Mon)
rather than 2027-10-04..10-10. The snap added in 224fe7a only ever covered
window_mode == 'fixed'; 'flexible' wishes were unaligned at both stages.

project_window now snaps both modes. A flexible bound is still a bounding
range, but it keeps its weekday alignment year over year with its span held
fixed, so the search space never shrinks and a bound that is exactly as long
as the target (its only candidate) repeats week-shaped.

_rank_candidate gains a Monday-start term between cost and start, so equal-cost
candidates break on week alignment instead of "earliest". It sits after cost
deliberately: a cheaper non-Monday start still wins, because red days outrank
alignment.

_reuse_already_funded_window would otherwise freeze a pre-existing misaligned
placement forever, so it now releases a year whose reuse winner is misaligned
when a fresh search ranks strictly better -- never when one of its days is
pinned or excluded, so a deliberate per-day override always survives.

Migration 008 realigns flexible series already materialised under the old rule;
projection runs once, at create/update, so nothing repairs them on read.

Alongside this, the planner now says when it moved a period to catch red days.
WindowOutcome carries shift_gain_days (the saving over the naive bound-start
placement) and the calendar toasts it, once, on the sync that decided it.
A fixed window is never auto-moved -- its "exact requested placement,
unconditionally" guarantee stands -- but its shift suggestion is no longer
hidden behind a shortfall, so a fully-funded one can surface a cheaper week too.

Editing a period in the popover now also sends window_mode: 'fixed' with a
matching target. Preset chips create flexible wishes; dragging one down to an
exact week left it flexible with a week-long bound, which is the degenerate
single-candidate case that produced the reported dates.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DXPBfr1v7F71t6QcbHCaaT

backend/tests/unit/test_services/test_allocation_excluded_days.py

@@ -140,7 +140,19 @@ class TestExcludedDayIsNeverPlaced:
 
         outcome = proposal.outcomes[0]
         assert outcome.shortfall_days == 0
-        assert outcome.remedies == []
+        # None of the three genuinely shortfall-gated remedies fire for a
+        # zero-shortfall window -- the exclusion did not create a gap to
+        # remedy. This used to be `remedies == []` outright, but the
+        # `shift_window_into_free_days` suggestion (§todo item, red-day
+        # shift toast) is deliberately NOT shortfall-gated for a `fixed`
+        # window any more: a fully-funded fixed window can still surface
+        # "moving this frees N days", and this Feb 1-7 window genuinely has
+        # a cheaper nearby placement. See `_Ledger._build_remedies`.
+        assert {r.kind for r in outcome.remedies} <= {"shift_window_into_free_days"}
+        assert not any(
+            r.kind in {"reduce_preschool_reserve", "carry_vacation_forward", "lower_priority_wish"}
+            for r in outcome.remedies
+        )
         # `weeks_funded` still tells the truth about what was actually
         # placed: 6 of the window's 7 days (4 funded + Sat + Sun).
         assert outcome.weeks_funded == round(6 / 7, 2)