Signup: logged-in user can create unlimited orphan pending member rows

[rubin110]

Discovered while running pre-merge verification on PR #284. Full context in .claude/notes/2026-05-20-signup-flow-adhoc-findings.md — Finding 15.

signup_submit does not check session.get('user'). A logged-in user can POST /signup/submit with an arbitrary new email and create a fresh pending member row that is not linked to their session in any way.

Reproduction (on dev)

1. Dev-login as Ada Lovelace (id=1) — confirm /dashboard returns 200 with Ada's info.
2. POST /signup/submit from the same session, with a NEW email and a unique username.
3. Result: HTTP 302 → /signup/payment?email=…. New member row created in the DB (id=62 in our repro).
4. Ada's session is untouched. /dashboard still renders her id=1 data.

POSTing with the SAME email as the logged-in user correctly routes to /signup with the "already exists" flash — i.e., the email-collision check catches the same-email case. The gap is only for new emails.

Implications

• A logged-in user can mass-create pending member records by scripting POSTs to /signup/submit. Each one fills the DB with orphan rows that admin tooling must manually clean up.
• Combined with Signup: enumeration via /signup/check-email + /api/check-username + missing rate-limit #292 (signup enumeration + missing rate-limit) and Signup: no server-side validation of identity fields (age, required, length, birthday format) #293 (no server-side validation), this becomes an unauthenticated-attacker-with-stolen-session DoS vector against the admin onboarding queue.
• UX bug as well: a confused logged-in user on a shared browser could double-sign-up without realizing they're already a member.

Suggested fix shape

Add a session-already-authenticated short-circuit at the top of both signup_check_email and signup_submit:

if session.get('user'):
    flash('You are already signed in.', 'info')
    return redirect(url_for('member_dashboard'))

One-line guard per endpoint. Should NOT touch signup_start (GET /signup) since the Finding 5 fix in PR #284 already preserves the logged-in user's session on visit; consider whether to redirect them to dashboard or render the signup page as today.

Context: PR #284