Phase 5: Create modal error handling and accessibility (E2E)

[aasimsyed]

Subtask of #1994 (Phase 5 of E2E Create Flows epic). Optional polish after happy-path specs (Phases 2–4). Builds on existing create modal coverage and FAQ/Resource error patterns.

Scope

(1) Error handling — Ensure create flows behave predictably when the create API returns 4xx/5xx. (2) Accessibility — Run axe against create modals when open so regressions in modal markup are caught in CI.

Deliverables

A. Error handling

• In each of the create modal specs (event-create-modal, organization-create-modal, group-create-modal), add at least one test that mocks the relevant create endpoint / mutation to return an error (e.g. 422, 403, or 500 with a JSON detail or message body consistent with the backend).
• Assert user-visible behavior: error toast (or equivalent) and that the modal does not close or follows the same rules as other mutation error tests (align with FAQ/Resource server-error specs under frontend/test-e2e/specs/all/**/**-server-errors.spec.ts).
• Document which routes or page.route patterns match useEventMutations().create, useOrganizationMutations().create, and useGroupMutations().create for stable mocks.

B. Accessibility

• Run axe in the browser while each create modal is open — at minimum step 1 of ModalCreateEvent, ModalCreateOrganization, and ModalCreateGroup (extend or mirror the approach used in event-create-modal.spec.ts if axe is already partial there).
• Prefer a small shared helper (e.g. runAxeInModal(locator)) if it reduces duplication; otherwise per-spec blocks are fine.
• Fail the test on serious axe violations per project E2E a11y conventions (FRONTEND_TESTING.md, existing accessibility specs).

C. Notes

• Phase 5 can be split across multiple PRs as long as both A and B are tracked here.
• If a modal shares components with other flows, one axe test per modal root is enough unless steps differ materially in DOM.