feat(admin): forms & surveys

Summary

Form builder for membership renewals, event RSVPs, working-group sign-ups, and ad-hoc community surveys. New ground — no schema today.

Requirements

• Brainstorming → spec under docs/superpowers/specs/. Schema design is part of the spec.
• Decide form-builder approach during brainstorm: build in-house (custom JSON schema + renderer), use a hosted service (Tally / Typeform / Formspree), or a hybrid (host the schema + render in our SPA, store responses in our DB).
• /admin/forms — list, create, archive forms.
• /admin/forms/:id/responses — view / export responses, basic analytics.
• Public render path: forms can be embedded into apps/web pages or stand alone at /forms/:slug.
• Response routing: trigger downstream actions (e.g., RSVP form populates event_attendances, renewal form updates org_memberships).

Context

Foundation must ship first (#1956). Form builder is conceptually orthogonal to most other admin surfaces — could ship anytime after foundation, ordering depends on operational urgency.

Implementation Notes

• Privacy: forms collect personal data; design the consent capture and retention model deliberately.
• This subsystem may justify its own R2 bucket for file uploads on form responses.
• "Hybrid hosted-service" path (e.g., Tally) is the YAGNI default until form needs outpace what an embed can do.

Start with the foundation work in #1956, then read the existing admin routes and apps/web entry points. Create the required spec under docs/superpowers/specs/, including the schema, implementation approach, privacy model, and response routing. Done means the team has approved the approach and the listed admin, public, response, and export flows are implemented.