Activity

Why

A cleaner (Betty) did a clean (client Donna) and was never paid — the booking was accepted but the client never paid, and nothing surfaced it. Investigation found this is a recurring gap, plus payouts that had paid out at Stripe were showing as "processing" because a webhook was missed.

This PR is the proactive monitoring half of the fix (the deeper "take payment at booking" change is scoped separately for sign-off). It gives admins eyes on the problem before a cleaner complains.

What

• PaymentWatchlist service — one shared query producing four buckets:
  • Accepted-but-unpaid bookings (the Betty/Donna case)
  • Direct bookings with no cleaner response >48h
  • Failed payments (last 30 days)
  • Payouts stuck past 24h (unconfirmed)
• Admin "Needs Attention" page (/admin/attention) reusing that service, with client/cleaner phone numbers for chasing and links into each job.
• Scheduled notifications to all admins (dynamic, role-based — no hardcoded addresses):
  • Mon/Thu summary (payments:watchlist-summary)
  • Daily urgent alert for imminent unpaid cleans (payments:watchlist-urgent)
  • Sends nothing when all clear — silence means no action needed
• PayoutReconciler + hourly payouts:reconcile — self-heals payouts stuck after a missed transfer.paid webhook by checking the real status at Stripe, so a paid cleaner never looks unpaid again.

Testing

• 25 new tests: every watchlist bucket (positive + negative cases), the reconciler (Stripe mocked the same way as existing payment tests), and the commands (sends to all admins / nothing when empty / urgent only when imminent).
• Full admin + payment + console + Stripe-webhook suites green (204 passing).
• pint, eslint, prettier clean.

Not in this PR (scoped separately)

The root-cause fix — taking/holding payment at booking time (booking.com-style: card on file, charge ~24h before the clean) + mandatory mobile at booking — needs founder sign-off as it changes the money flow. Planned as a follow-up.