fix(scheduler): persist last_run_at per-tenant schema to stop duplicate schedule fires

[paktusov]

Problem

The custom multitenant DatabaseScheduler (workflow/schedulers.py) loads schedules across all tenant schemas and keys entries "<schema>:<name>", but does not override sync(). The base django-celery-beat sync() saves each dirty entry's last_run_at / total_run_count under whatever DB search_path is active at sync time — not the entry's schema. So the bookkeeping lands in the wrong schema (or nowhere) and last_run_at never advances for the tenant.

Consequence: the crontab stays due on every beat cycle until the workflow task itself finally runs and stamps last_run_at. When the workflow launch is delayed (busy workers / ordering gate), beat re-sends the same scheduled task several times.

Observed (realm04pdn / space0uph9, Mars Capital)

portfolio_history (cron 30 1) fired 3–4×/night; register / price_history fired once. Beat log:

01:30:00  Sending due task portfolio_history
01:30:30  Sending due task portfolio_history
01:35:32  Sending due task portfolio_history
01:40:34  Sending due task portfolio_history

DB tell-tale: total_run_count = 0 on all schedules despite nightly runs. Result: 3–4× duplicate heavy calculations in parallel, duplicate PortfolioHistory rows, ~9h runtime instead of ~2h.

Fix

Override sync() to set_schema_from_context({"space_code": <entry schema>}) per dirty entry (schema parsed from the "<schema>:<name>" key) before save(). Entries that can't be saved are re-queued for the next sync, matching base-class semantics.

Verification

• After deploy, total_run_count should become > 0 (regression signal).
• A schedule whose launch is delayed should fire exactly once.

Notes

Space-level stop-gaps are already live for space0uph9 while this lands: a duplicate-run guard in the helper-calculate-portfolio-history workflow module + retimed cron. This PR is the platform root fix and covers all schedules / tenants.

🤖 Generated with Claude Code