Automations owned by removed members keep firing as them

[ryw]

Problem

Automations have an owner_user_id ("Run as") — scheduled runs execute as
that user and use their per-user tool connections (Composio / Native-MCP).
But removing a member from a workspace only deletes their workspace_member
row; it does not touch automations they own.

So an automation owned by an ex-member keeps firing as them, using their
connections, after they've been removed from the workspace. Nothing reassigns,
pauses, or warns. (Their user row also persists — run.created_by and
automation.owner_user_id are ON DELETE RESTRICT.)

Why it matters

• A schedule silently keeps running under a departed user's identity/credentials.
• The connections it relies on are that ex-member's; if they revoke them (or the
  tokens expire with no one to re-auth), the schedule fails with no clear owner
  to fix it.
• Security/offboarding hygiene: a removed person's access effectively still
  drives workspace automation.

Options to consider

When removing a member (removeWorkspaceMember), for automations where they're
the owner_user_id:

• Warn the admin: "N automations run as this person — reassign or they'll
  keep running as a non-member / break."
• Pause those automations (set inactive) until an admin reassigns the owner.
• Block removal until automations are reassigned (heaviest).
• Reassign to the removing admin (surprising; probably not default).

Likely best: surface the count + a reassign step on removal, and pause schedules
whose owner is no longer a member.

Related

• Migration 0023_automation_owner_user.sql (introduced owner_user_id + the
  "Run as" picker).
• Companion UI: show the "Run as" owner on the automations list so this is
  visible day-to-day.