Steps to reproduce:

1. Create a maintenance request with these values:

   * Maintenance Type: Preventive
   * Recurrent: enabled
   * Repeat Every: 1 day, forever
   * Scheduled Date: today
2. Confirm that an activity is created for the responsible user.
3. Mark the activity as done.
4. Move the request to `Repaired`, or another done stage.
5. Check the newly generated request in the recurring series.

When a recurrent maintenance request is moved to a done stage, Odoo creates the next request in the series.

The existing activity on the completed request is marked as done and automatically unlinked by `activity_feedback()`.

Previously, `activity_update()` was then called on all requests whose stage changed. Since the completed request no longer had a pending activity, this created a new one on that request.

The newly generated recurring request also received its own activity, resulting in one activity on the completed request and another on the new request.

Only call `activity_update()` for requests that remain in a non-done stage. This prevents a new activity from being created on a completed request while preserving the reminder on the next recurring request.

opw-6409396


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#279470

The main issue is that the stale analytic account is **not actually cleaned in multi-edit**:

- When an analytic account ID is no longer found, the usual behavior is to call `save()` to remove the stale ID from the analytic distribution.

- Since 19.0, we introduced the `load()` logic in the multi-edit case. So after `save()`, when `multi_edit` is enabled, the record is reloaded.

- This reloads the stale analytic distribution again. Also, `dataToJson()` in multi-edit only returns the `__update__` payload. So after `jsonToData()` removes the missing account, it can end up sending something like:

```js
{ __update__: [] }
```

  As a result, the cleaned `analytic_distribution` never reaches the server, unlike in the normal widget.

- This means the stale account is loaded again, the cleanup is triggered again, and we end up in a loop. During this process, the component can eventually be destroyed, so the cleanup behavior becomes unreliable.

Because of this, we decided not to call `save()` in the multi-edit case. Skipping it avoids the cleanup loop. The stale account will eventually be cleaned up when the relevant record is properly saved.

**opw-6405220**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr