Bug: Changing the care watering interval does not reschedule the pending future task

[nolte]

Summary

On the plant-instance Pflege tab (/pflanzen/plant-instances/{key}#care), editing the watering interval (Gießintervall) persists the new value but does not recalculate the already-pending future care task. The existing watering reminder keeps its old due date and its stale instruction text (e.g. "Water DAHLI-0710-3LN (every 7 days)."), so a user who shortens or lengthens the interval sees no change to the upcoming activity.

Observed on DAHLI-0710-3LN (/pflanzen/plant-instances/18333391#care): after changing the interval, the assigned task still reads "every 7 days" and its due date is unchanged.

Root cause

The care-profile update path writes the new interval to the CareProfile but never re-schedules the corresponding pending task.

• Frontend submits the interval via the care profile form:
  • src/frontend/src/pages/pflege/components/CareProfileForm.tsx:222 → watering_interval_days
  • src/frontend/src/api/endpoints/careReminders.ts:48 → PATCH /api/v1/care-reminders/plants/{plant_key}/profile
• Backend endpoint: src/backend/app/api/v1/care_reminders/router.py:38-46 (update_profile)
• Backend service (the gap): src/backend/app/domain/services/care_reminder_service.py:175-183

  def update_profile(self, plant_key: str, updates: dict) -> CareProfile:
      profile = self._repo.get_profile_by_plant_key(plant_key)
      if profile is None:
          raise NotFoundError("CareProfile", plant_key)
      data = profile.model_dump()
      data.update(updates)
      updated = CareProfile(**data)
      return self._repo.update_profile(profile.key or "", updated)

  It only persists the field. The next watering task's due_date and instruction text are computed from the interval at task-creation time — via ensure_next_watering_task (:744), advance_watering_task_after_log (:288), build_care_reminder_task (:65) and care_reminder_instruction (:43) — which run on confirmation/logging, not on an interval edit. So a pending, not-yet-confirmed task keeps the old cadence until the next confirmation regenerates it.

The interval label baked into the instruction string ("every N days") confirms the task text is a snapshot, not derived live.

Proposed fix

In update_profile, when a task-interval field actually changes (watering_interval_days, and by the same logic fertilizing_interval_days, pest_check_interval_days, humidity_check_interval_days, repotting_interval_months), reschedule the corresponding pending care task:

• Recompute its due_date from the new interval relative to the last confirmation (or now if none), reusing the existing ensure_next_watering_task / scheduling helpers rather than duplicating the cadence math.
• Refresh the instruction text so "every N days" reflects the new interval.
• Only touch pending tasks; do not resurrect completed/skipped ones or create duplicates (respect auto_create_watering_task).
• Consider watering_interval_learned interaction: an explicit interval edit should take precedence over / reset the learned value as appropriate.

Acceptance criteria

• Changing the watering interval on the Pflege tab updates the pending watering task's due date to match the new interval (verified on a plant with a pending watering reminder, e.g. DAHLI-0710-3LN).
• The task instruction text ("every N days") reflects the new interval after the edit.
• No duplicate pending tasks are created; completed/skipped history is untouched; auto_create_watering_task=false is respected.
• The same behaviour holds for the other editable care intervals (fertilizing, pest-check, humidity, repotting).
• Backend unit tests cover: interval change reschedules the pending task; unchanged interval is a no-op; no pending task → nothing created unless auto-create is on.
• ruff / pytest pass.

Notes

• URL from report: /pflanzen/plant-instances/18333391#care.
• Related scheduling logic already exists (ensure_next_watering_task, advance_watering_task_after_log) — the fix is wiring it into the interval-edit path, not new cadence math.

[nolte]

Resolved via #663 (merged to develop). Auto-close did not fire because the automerge app merges with an app token; closing manually.