[BUG] alerts/batch/update: alert_owner_id overridden with current_user.id when alert has no owner

[tcl-ass]

Describe the bug
When batch-assigning an alert that has no owner (alert_owner_id = NULL) to a specific user via Assign → [user], IRIS ignores the provided alert_owner_id value and assigns the currently logged-in user instead. A second identical batch update correctly applies the intended user.

To Reproduce

1. Go to Alerts
2. Select an alert with no owner (alert_owner_id = NULL)
3. Click Assign and select a user different from the logged-in user (e.g. JMA)
4. Observe the alert is assigned to the logged-in user instead of JMA
5. Repeat the same action
6. Observe the alert is now correctly assigned to JMA

Expected behavior
If alert_owner_id is explicitly provided in the updates payload, it should be applied regardless of the current value of alert_owner_id.

Root cause
In app/blueprints/alerts/alerts_routes.py, inside alerts_batch_update_route():

if getattr(alert, 'alert_owner_id') is None:
    updates['alert_owner_id'] = current_user.id

This overwrites the alert_owner_id from the client payload when the alert has no existing owner, making Assign → [user] behave like Assign to me on the first call.

Suggested fix

if getattr(alert, 'alert_owner_id') is None and 'alert_owner_id' not in updates:
    updates['alert_owner_id'] = current_user.id

Screenshots
N/A

Desktop:

• OS: Ubuntu 24.04
• Browser: Firefox 151.0.4
• Version: IRIS v2.4.27
• Docker image: ghcr.io/dfir-iris/iriswebapp_app:v2.4.27

Additional context
The UI explicitly offers two distinct actions — Assign to me and Assign → [user] — making this behavior particularly confusing since both produce the same result on alerts without an existing owner.

Workaround: perform the batch assign twice.