feat: zustand store + move feedback modal to builder page

[bookwormsuf]

Problem

The admin feedback modal lives on the dashboard (WorkspacePage) where admins rarely spend time. Trigger state is stored in sessionStorage, which doesn't integrate with React's rendering cycle and can't carry metadata like which action triggered the prompt.

Solution

Replace sessionStorage with a zustand store and move the feedback container from the dashboard to the form builder page (AdminFormLayout), where admins actively work. The modal still shows the existing thumbs up/down UI. The feature flag from PR 1 gates the render.

Key changes:

• New adminFeedbackStore.ts (34 lines): zustand store with isEligible, triggerSource, formId
• AdminFeedbackContainer uses store selectors instead of sessionStorage
• Container moved from WorkspacePage to AdminFormLayout (behind useFeatureIsOn)
• Field-edit triggers (useEditFieldForm, PaymentsInputPanel) call setEligible('field-edit', formId) instead of setting sessionStorage
• useBuilderFields cleaned up (removed 24 lines of old threshold logic)
• Desktop-only check removed (mobile admins now see the prompt too)
• sessionStorage.ts deleted

This is PR 3 of 5 in the admin satisfaction revamp stack:

1. Feature flag (feat: gate admin feedback behind feature flag #9683)
2. Backend schema + validation (feat: extend admin feedback schema for 1-5 rating + triggers #9684)
3. Zustand store + move modal (this PR)
4. Publish + workflow triggers
5. Star rating UI

Breaking Changes

No. This PR keeps the existing thumbs up/down UI and only changes where the modal renders (builder instead of dashboard) and how trigger state is stored (zustand instead of sessionStorage). The 5-star rating UI is a later PR (5) in this stack. PR 2 (#9684) widened the backend to accept ratings 0-5 so it's forward-compatible, but the frontend here still submits 0/1.

Tests

Build

• pnpm build passes

Modal show/hide (flag ON)

• Edit a single field on a form → modal becomes eligible and appears on the builder page
• Add/edit a payment input → modal becomes eligible and appears
• Navigate to the dashboard after triggering → no modal there (only renders in builder now)
• Modal does NOT reappear within the display-frequency window of the last showing
• Modal reappears after the frequency window elapses AND eligibility is re-triggered
• After showing once, eligibility resets (won't re-fire until a new field/payment edit)
• Mobile viewport: modal appears (desktop-only check removed)

Flag OFF

• No modal anywhere (dashboard or builder)

🤖 Generated with Claude Code

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[scottheng96]

Could we update the description?

1. Include TCs to determine the expected behaviour of how and when the modal should show up
2. Breaking change -> Same thumbs up/down UI, just in a different location and with a different state management approach. I believe this is incorrect. We are now using the 5 star rating after PR 2?

[bookwormsuf]

Got it!

Added test cases for when the modal shows and when it doesn't.

On the breaking change: this PR still uses the thumbs up/down UI. It sends 0/1 via the old AdminFeedbackRating enum. PR 2 (#9684) just widened the backend to accept 0-5 so it's forward-compatible. The 5-star UI comes in PR 5. So "Breaking Changes: No" is right for this PR. I reworded the stack section to make the ordering clearer.