fix(api): mirror assignees → assignee_ids so Lark DM actually fires

[JOBYINC]

Summary

PR #12 was based on a wrong hypothesis (the task brief said "strongly suspect model_activity"; that was wrong). Real Lark fan-out path:

issue_activity.delay(…)
  → create_issue_activity()                # issue_activities_task.py:557
    → if requested_data.get("assignee_ids") is not None:  # line 581 — THE GATE
        track_assignees()                  # writes IssueActivity(field="assignees")
  → bulk_create(issue_activities)
  → dispatch_lark_for_activities(rows)     # lark_notify_task.py:44
    → notify_issue_assigned_task.delay(…)  # the Lark DM

The plane/api/serializers/issue.IssueSerializer uses assignees as its write key. The plane/app/serializers/issue.IssueCreateSerializer (used by the web UI) uses assignee_ids. The activity tracker's gate hard-codes assignee_ids, so the system-token create path never triggers track_assignees and never produces an assignee row for the Lark dispatcher to fan out.

Fix (3 lines): when building the payload for issue_activity.delay(...), mirror assignees into assignee_ids so the gate fires. The serializer.save() above is untouched — it still consumes the original assignees key.

Evidence from prod (before this fix)

LARK_NOTIFICATIONS_ENABLED=1 is set in both plane-api-1 and plane-worker-1 containers. Worker logs show issue_activity task received with the correct issue.activity.created payload — but requested_data only has \"assignees\": […], not \"assignee_ids\":

{\"type\": \"issue.activity.created\",
 \"requested_data\": \"{…, \\\"assignees\\\": [\\\"92184…\\\"]}\",  ← gate at line 581 misses
 …}

No notify_issue_assigned_task is fired downstream.

Why this matters

• Tom's task-manager flow (create task on behalf of user) lands the task correctly in the user's My Tasks bucket but never DMs them on Lark.
• PR fix(api): personal-tasks endpoints must fire model_activity (Lark bot fan-out) #12's model_activity addition is harmless / correct-for-webhook-subscribers but does NOT trigger the Lark DM (different code path entirely).

Files

• apps/api/plane/api/views/personal_task.py — alias assignees → assignee_ids in the activity_payload passed to issue_activity.delay. Comment explains the gate.
• apps/api/plane/tests/contract/api/test_personal_tasks.py — adds test_post_requested_data_includes_assignee_ids_for_lark_gate which asserts the precise contract the gate needs.

Test plan

• pytest plane/tests/contract/api/test_personal_tasks.py -v → 15 passed (was 14 before round 2).
• Confirmed RED before fix: assertion fails with payload showing only assignees key.
• After merge + rebuild + redeploy: Tom POSTs a personal task → assignee receives Lark DM with card_issue_assigned.
• PATCH still works (existing test covers; PATCH path already maps both keys via ATTRIBUTE_MAPPER).