feat(admin): integrate form builder for events, surveys, and custom forms

Summary

Add a drag-and-drop form-builder surface to the admin UI so staff/super_admins can compose forms (event registrations, surveys, applications, custom intake) without code, then publish them to the public site for members to fill out.

Requirements

• Evaluate candidate libraries and pick one. Initial shortlist:
  • React Hook Form Form Builder — light, generates RHF schemas; minimal opinions
  • Coltorapps Builder — headless, extensible; bring-your-own UI
  • Form.io open source — heavyweight; bundled renderer + builder + server bits we may not want
  • SurveyJS (React) — mature; commercial-license check required
• Define the form-schema persistence model (likely `forms` + `form_submissions` tables, schema stored as jsonb)
• Admin route at `/forms` (or similar) gated by an appropriate policy (likely `canEditForms`, staff+)
• Builder UI styled consistently with the existing admin design system (white background, rounded purple primaries, cool-toned palette — not a vendor's default theme)
• Server-side schema validation when submissions land (don't trust client-built schemas blindly)
• Public renderer on the member-facing site that consumes the same schema
• Submission storage + a basic admin view of submissions per form
• Audit-log entries for form publish / unpublish / edit actions

Context

This is groundwork for several near-term workflows: annual event registration, post-event surveys, leadership-position applications, ad-hoc community polls. Each one would otherwise be a one-off Google Form or a custom-coded page.

The four candidate libraries have very different shapes — picking one is the load-bearing decision. Library evaluation should weigh: license, bundle size, theming flexibility, schema portability (can we read the schema server-side without the builder runtime?), and how well the renderer integrates with our existing Tailwind/design-system surface on the public site.

Implementation Notes

• The form schema should be portable: serialized JSON that we own, not a library-specific binary blob.
• Renderer on the public site needs to work without authoring dependencies (admins build, members render — different bundles).
• Permissions: who can build forms? who can publish? who can read submissions? Tie into the existing `canEditMembers` / role tier model.
• Consider whether form approval (next issue) is a v1 feature or a follow-up gate.

Start by evaluating the four listed builder libraries against license, bundle size, theming, schema portability, and renderer integration. Then inspect the existing admin design system and canEditMembers/role-tier model to shape /forms access. Done means a library choice and a defined path for schema persistence, validation, rendering, submissions, permissions, and audit entries.