Design how poll finalize should interact with the payment gate

[leahpeker]

Context

While scoping PR #1272 (Issue 1238 — poll finalize bypasses RSVP capacity), payment-gate handling was pulled out as a separate design question rather than folded into the capacity fix.

Poll finalize auto-seats yes-voters directly (no RSVP action from the member). On a payment-gated event, a normal RSVP flow requires the member to self-attest paid_confirmed before they're seated as attending — but a poll voter never goes through that step. Auto-seating them as attending on a gated event would skip payment confirmation entirely; waitlisting them instead just defers the problem, since waitlist promotion (promote_from_waitlist in backend/community/_event_helpers.py) doesn't check the payment gate either, and there's currently no way for a waitlisted member to confirm payment at all (no UI, no owner-facing endpoint — only a host override via PATCH .../rsvps/{user_id}/payment/).

So this isn't a simple bug fix — it's an open design question about how polls, auto-seating, and the payment gate should interact together.

What needs to happen

Work out the intended behavior for a poll-seated voter on a payment-gated event. Rough direction discussed: seat/waitlist them as usual, but notify them that their spot isn't confirmed until they pay, making clear the host may remove them if they don't — and give the host a clear way to manage/remove unpaid poll-seated attendees. This likely also needs the broader "waitlisted member can't self-confirm payment" gap addressed (no owner-facing confirm-payment path exists today outside of re-RSVPing).

Acceptance criteria

• TODO — decide and implement how poll finalize should interact with the payment gate (seat vs. waitlist vs. something else, notification content, host management path).

[leahpeker]

Additional detail carried over from a stale code-review comment on PR #1272 (#1272 (comment)), left against an earlier version of _poll_finalize.py that has since been removed when the PR was scoped down to capacity-only:

Unpaid poll voters are notified as "waitlist promoted" when they were never promoted

The old seat_yes_voters collected voters who got waitlisted because they're unpaid on a payment-gated event, then called create_waitlist_promoted_notifications(event, unpaid_user_ids, unpaid_user_ids) — passing the same list as both promoted_user_ids and unpaid_user_ids.

create_waitlist_promoted_notifications stamps every id in promoted_user_ids with notification_type=NotificationType.WAITLIST_PROMOTED. These voters went straight from no RSVP to WAITLISTED via the payment gate — they were never previously seated or waitlisted, so there's nothing to be "promoted" from. Compare the legitimate caller in promote_from_waitlist, where promoted_user_ids are users whose status was just changed to ATTENDING and unpaid_user_ids is a genuinely smaller subset.

The message copy happens to read correctly ("your spot isn't confirmed until you pay") since user_id in unpaid is trivially true here, but the persisted notification_type is wrong on every payment-gated poll finalize that leaves a yes-voter unpaid.

Whatever design this issue lands on for notifying unpaid poll-seated voters, make sure it uses a notification type that actually matches what happened to them (never seated/waitlisted-from-nothing is not a "promotion"), not a reused WAITLIST_PROMOTED type.