[Feature]: e2e dark+light contrast coverage for data-dense / auth-gated pages

[dqnykamp]

Before submitting

• I searched existing issues and did not find a duplicate request.

Affected area

Developer experience / tooling

Layer

Frontend (apps/app), Infrastructure / CI

Problem

During the dark-mode accessibility sweep (branch upgrade-doenetml-dark-mode), an audit of the a11y test coverage found ~25 routes with zero color-contrast coverage in either the e2e (checkAccessibility) or component (checkContrast) suites.

Component-level specs were added for the pages that mount cheaply — static pages and the empty state of a few data pages. But a set of data-dense / auth-gated pages can't be covered cheaply at the component level: they need realistic loader data, authenticated fetchers, populated Content[], or the DoenetML viewer. Their contrast — especially in dark mode, where hardcoded light colors hide — is still unverified. Two real dark-mode bugs were found on such pages during the sweep (the assignment-data bar chart and the compound-editor empty state), which is what prompted this audit.

Still uncovered (no contrast scan in either suite):

• Populated (non-empty) states of Curate, Trash, SharedWithMe (empty states are now covered by component specs)
• Students, SharedActivities, ImageDetails
• DoenetMLComparison
• StudentAssignmentScores, AssignmentResponseStudent, AssignmentResponseOverview (populated tables + charts)
• ConfirmSignIn, ChangeName (as a routed page), EnterClassCode / AssignmentViewer routed states
• CompoundEditor and its routed sub-tabs; documentEditor history / remixes / settings / library routed sub-tabs
• RawViewer (/embed/:viewId) — note it intentionally opts out of dark mode, so needs a deliberate decision
• ErrorPage (needs a thrown route error to render)

Additionally, three existing full-page e2e scans run light-only (not inside the colorModes loop): scratchPad.cy.ts, documentEditor.cy.ts, activityViewer.cy.ts.

Proposed solution

Extend the existing e2e a11y suite (packages/e2e-tests, basicTests.cy.ts), which already wraps its describes in a colorModes = ["light","dark"] loop that gates on the group1 job, to:

1. Navigate to each uncovered page with seeded data (reuse the existing createContent / assignment helpers), then checkAccessibility — so both modes run.
2. Bring the three light-only scans into the colorModes loop.
3. Keep the DoenetML viewer canvas itself out of scope (the engine handles its own dark mode via the pinned doenetmlVersion); scan only the app chrome around it.
4. Make an explicit call on RawViewer's dark-mode opt-out.

Alternatives considered

Component-level mounts (as done for the static + empty-state pages in this sweep) were rejected for these pages: the fixtures (full Content[], auth, viewer) are large and brittle, and the empty-state component specs already cover the surrounding chrome. e2e with seeded data is the proportionate vehicle.

Additional context

• Follow-up to the dark-mode accessibility sweep in feat: site-wide dark mode (DoenetML 0.7.21) with accessibility tests #3010 (upgrade-doenetml-dark-mode), which added the a11y audit this issue is drawn from.
• Component coverage already added in that PR: GetInvolved, Events, About, QuickLinks, SignIn, SharedWithMe, Trash, Curate (+ ScoreSummaryChart, CompoundActivityEditor helper). This issue tracks the pages that PR deliberately left for e2e.
• Sibling issue: contrast coverage for transient/interactive UI states [Feature]: contrast coverage for transient/interactive UI states (both color modes) #3014.