DHMemberPortal: make signup scaffolding writes best-effort (#283 bandaid)

[rubin110]

Summary

Bandaid for #283. /signup/submit was non-atomic — 8 sequential HTTP calls inside one try/except — so any transient failure after add_member succeeded would abort the redirect to /signup/payment and strand the user with a half-created row.

• Critical path (get_access_token, get_member_id, add_member) still bounces the user to /signup on failure.
• Once add_member returns a member_id, the seven secondary JSONB writes (connections/status/forms/notes/access/authorizations/extras) run in a for-loop with per-step try/except. Each step logs success at INFO and failure at ERROR; the loop never throws.
• The user always reaches /signup/payment once the row exists.
• Bumped the seven secondary helpers in dhservices.py from timeout=10 → timeout=20 as cheap insurance against slow DHService responses.

What this PR does not do

• Does not add a /signup/resume escape hatch for orphan members already in production (issue Signup: members sometimes never reach Stripe — non-atomic /signup/submit + no recovery path #283 option B). Open follow-up.
• Does not change DHService's add_update_* to return HTTP 5xx on internal failure (option C). Open follow-up.
• Does not batch the secondary writes into one transactional endpoint (option D). Belongs in the planned full signup-flow redesign.

Known trade-offs

• update_member_access is also used by the dashboard Keys page profile save. The 20s timeout now applies there too. The worst case is a 20s synchronous Flask wait on a real DHService timeout (previously 10s); normal writes are sub-second.
• The "Sign up successful! Please complete payment." flash fires even if all 7 scaffolding steps failed. By design: the user is unblocked, admin tooling addresses the partial row later. The codebase has no partial-success flash convention.

Verification

Manual on dev (https://ps1-member.mime.starset.net) via Chrome devtools:

• Happy path: walked the full flow with a fresh email; Stripe pricing-table iframe renders both tiers; DB row has all 7 JSONB columns populated; logs show 8 INFO lines (Created new member with ID: N + 7 × Signup member N: <label> initialized).
• Fault injection (inline raise on forms + notes): rebuilt with a temporary raise RuntimeError mid-loop. User still reached /signup/payment. DB row has forms=null and notes=null as expected; other 5 columns populated. Logs show 2 ERROR lines + 5 INFO lines. Reverted before commit.
• Existing-email retry: confirmed the early-return guard fires on a duplicate signup.

Test plan

• Watch for any new signup-related error log lines in prod once deployed
• Verify status->>'stripe_product_id' lands as expected via the ST2DH webhook for a real new signup (the scaffolding loop creates a pending status row; ST2DH writes stripe_product_id into the same JSONB on payment)
• Spot-check update_member_access from the dashboard Keys tab still saves within the 20s ceiling

🤖 Generated with Claude Code