[BUG] `user_login` automation/alert trigger never fires from a real SSH login

Title: [BUG] user_login automation/alert trigger never fires from a real SSH login

Platform: N/A

Server Installation Method: Docker

Version: 2.7.1 (revision 76fd9eedbf0f7e853d5ffe40717cac126ffe6a98)

Troubleshooting

• I have examined logs and tried to find the issue
• I have reviewed opened and closed issues
• I have tried restarting the application
• I have checked open issues and ensured this is not a duplicate

The Problem

An automation (or legacy alert rule) with trigger user_login, scoped to a host, never fires when someone actually connects to that host over SSH. The notification pipeline itself is fine: manually running the automation, or testing the notification channel directly, both deliver successfully. Only the real SSH-login event never reaches it.

Cause: the automations migration (src/backend/utils/crypto-migration/automations-migration.ts) permanently stands down the old alert engine (supersededByAutomations = true in src/backend/hosts/metrics/alert-engine.ts) on first boot, since it runs once and never re-checks later. The real SSH-connect handler (src/backend/hosts/terminal/index.ts) still only calls the old, now-dead triggerLoginAlert(...). Nothing calls the new automations engine's onInternalEvent() with event: "user_login" — that call site does not exist anywhere in the codebase. So neither system can ever deliver this notification, regardless of configuration.

How to Reproduce

1. Create an automation with trigger {"kind":"internal_event","event":"user_login","hostSelector":{"kind":"host","hostId":<id>}} (via the API), attached to a notification channel.
2. Manually run it (or test the channel directly) — delivery succeeds.
3. Note last_run_at via GET /automations/:id.
4. Open a new SSH terminal session to the same host.
5. GET /audit-logs shows a new ssh_connect entry, but last_run_at is unchanged and no notification arrives.

Additional Context

Verified end to end: two manual runs delivered successfully, then three real SSH connections to the same host produced zero automation executions. Restarting the container made no difference (the migration flag persists in the settings table).

This report was investigated and written by Claude Code (Anthropic's CLI agent), working on behalf of a self-hosted Termix user.

Start with src/backend/hosts/terminal/index.ts and trace the real SSH-connect handler, then compare its triggerLoginAlert(...) call with the automations engine and onInternalEvent() flow. Review src/backend/utils/crypto-migration/automations-migration.ts and src/backend/hosts/metrics/alert-engine.ts to understand the superseded engine state. Done means a host-scoped user_login automation runs after a real SSH connection and updates last_run_at or delivers its notification.