fix(migrations): 7 tables carry updated_at but no created_at after alembic upgrade head, the same Base timestamp drift as #17996 #18392

Problem

Measured on a throwaway database after alembic upgrade head: these tables have an updated_at column and no created_at, while Base (autobot_shared user_management models) gives every mapped model both. Migration 063 (#10636) added only updated_at to a list of such tables; the created_at half was never reconciled.

Tables found (query: columns named updated_at minus columns named created_at, public schema): heartbeat_run_events, agent_connections, completion_feedback, user_voice_bundle, llc_activity_log, workflow_audit_log, role_permissions.

task_approval_links was the eighth; it is fixed inside #13421's S1 PR (migration 099) because its approval-inbox read path failed on it: column task_approval_links.created_at does not exist on selectinload(Approval.task_links).

Not yet known

Which of the seven are Base-mapped with a created_at attribute (a table the ORM never selects created_at from is harmless). Each needs that check before a migration is written; this issue does not claim all seven are broken, only that the schema drift exists.

Related

#17996 (llc_workspace_leases, same class), #14654 (audit_logs.updated_at), #10636, #13421.

Acceptance criteria

• Each table is classified: Base-mapped (needs created_at) or not (drift is harmless, say why).
• One idempotent migration adds created_at to every table that needs it (fix the class once, not one PR per table).
• A migration-gate test compares the Base metadata against alembic upgrade head and fails on any mapped column the schema lacks, so the next table cannot drift silently.