fix(lark): durable DB dedup for due-date reminder (stop repeat DMs)

[JOBYINC]

Problem

lark_due_reminder_task (hourly Celery beat) was DM'ing the same
assignee about the same issue dozens of times. The reported cause —
"missing 已提醒 mark" — is wrong: a mark existed, but it was a 25h
Redis key (cache.get/set). When the deployment's cache is
unavailable / non-shared across workers / evicting, the key never
sticks, so every hourly run re-detects the issue and re-sends.

Fix

Replace the cache-only dedup with a durable LarkDueReminderLog
row, claimed atomically via get_or_create on a unique
(issue, receiver, stage, reminder_date) constraint:

• Idempotent across the hourly cadence and across concurrent beat
  workers, regardless of cache health — fixed by construction, no DO
  access needed.
• Mirrors the existing EmailNotificationLog sibling +
  WorkspaceMember's soft-delete-aware unique idiom
  (unique_together incl. deleted_at + partial
  UniqueConstraint(condition=deleted_at__isnull=True)).
• A claim is released via hard delete on any failure, so a later
  run still retries — the once/stage/day slot is consumed only on a
  confirmed send (same intent as the old Redis check, now durable).
  Hard delete (not soft) because a failed claim has no audit value and
  soft-delete would leave a ghost row + queue a pointless cascade task
  per failure.

Changes

• LarkDueReminderLog model + migration 0124
• lark_due_reminder_task: Redis dedup → get_or_create claim; docstring updated
• 3 pytest cases

Test plan

• pytest plane/tests/unit/bg_tasks/test_lark_due_reminder_task.py → 3/3 pass locally:
  • sends once across 3 task runs (not once-per-run) ✅
  • failed send releases the claim, later run retries ✅
  • no-op when LARK_NOTIFICATIONS_ENABLED unset ✅
  • ⚠️ repo CI runs no Python suite — this was verified locally only; reviewer should re-run.
• manage.py check — 0 issues; makemigrations --check — model fully captured by 0124
• Deploy note: takes effect once deployed and migration 0124 applied on the environment running the beat.

Reviewer notes

• Pre-existing automation RenameIndex migration drift (would be 0125) is deliberately excluded — unrelated to this fix, predates it, belongs to the automation-merge owner (same pre-existing-debt family as the documented check:types/check:format items on preview).
• Pure Python change; no JS/TS touched.

[JOBYINC]

Admin-merging: CI fully green (this PR touches no JS/TS, so the pre-existing frontend check:types/check:format debt on preview is not in its --affected set; Python side clean).

Reviewer caveat carried from the description: the repo CI runs no Python suite, so the dedup logic was verified locally — pytest 3/3 (dedup-across-runs, retry-on-failure, disabled-noop), not by CI. The spam only actually stops once this is deployed and migration 0124 is applied on the host running the Celery beat.