Fix watch alert delivery model wiring and webhook failure handling

[DeepZone]

Motivation

• Correct a model wiring error where alert-delivery fields were accidentally placed on User instead of belonging to watch runs, which caused runtime errors during watch execution.
• Harden webhook delivery so failed alerts do not abort watch runs and to avoid storing large tracebacks in the DB.
• Ensure SQLAlchemy models align with the new Alembic migration so backend tests pass again.

Description

• Removed alert_delivery_status, alert_delivered_at, and alert_error_message from the User model and added them to the WatchRun model with nullable types matching the migration.
• Aligned model fields with backend/alembic/versions/0005_providers_and_changecase_workflow.py so ORM and migration are consistent.
• Hardened send_watch_webhook in backend/app/services/alerting.py to use response.raise_for_status(), retry based on ALERT_WEBHOOK_MAX_RETRIES, truncate error messages to a safe length, and return delivery status strings (sent / failed / skipped_*) instead of raising.
• Changed files: backend/app/models.py, backend/app/services/alerting.py (no API endpoints removed or behavioral breaking changes introduced).

Testing

• Ran backend unit tests with cd backend && pytest -q, result: 102 passed, 0 failed.
• Built frontend with cd frontend && npm run build, result: build completed successfully.
• Verified that the WatchService continues to write delivery status to WatchRun and that webhook failures are non-fatal and produce truncated error messages saved on the run.

---

Codex Task