Bug: "Leave feature flag?" dialog prompts twice and still discards data on Cancel

Bug description

PostHog shows a "Leave feature flag? Changes you made will be discarded." confirmation dialog when navigating away from a dirty feature flag form. The dialog itself has two bugs:

Bug A — Dialog prompts twice on Cancel. When the dialog appears and you click Cancel, the same dialog immediately re-appears. You have to click Cancel a second time to dismiss it.

Bug B — Cancel still discards the data. After clicking Cancel (twice), the navigation proceeds anyway and the form is wiped. Clicking Cancel is supposed to keep you on the page with your edits intact.

Steps to reproduce

1. Go to the new feature flag page (/feature_flags/new) or any existing flag edit page.
2. Edit any field — key, name, a release condition, or a JSON payload.
3. Trigger a navigation away from the page (e.g. switch browser tabs / click elsewhere) so the confirm dialog appears.
4. Click Cancel in the "Leave feature flag? Changes you made will be discarded." dialog.

Expected: Stay on the page, all edits preserved.

Actual:

• The same dialog re-appears, requiring a second Cancel click (Bug A).
• After dismissing it, navigation proceeds anyway and all form edits are lost (Bug B).

Reproduced on PostHog Cloud (us.posthog.com) on 2026-05-15.

Regression introduced by

This appears to be a regression from #54692 ("feat(feature-flags): add unsaved changes warning on edit page", merged ~2026-04-30), which added a beforeUnload interceptor to frontend/src/scenes/feature-flags/featureFlagLogic.ts.

Suspected root causes (from reading the code)

Bug A — double prompt: The new beforeUnload block in featureFlagLogic.ts does not have the tab-id / scene-tab-cache guard that products/actions/frontend/logics/actionEditLogic.tsx uses for the same scenario. In actionEditLogic.tsx the beforeUnload.enabled callback checks sceneLogic activeTabId vs the logic's own props.tabId and returns false for tab switches, with a comment explicitly noting "the logic stays mounted via the scene-logic cache". featureFlagLogic has no equivalent guard — it also doesn't import sceneLogic, FeatureFlagLogicProps has no tabId, and key() is keyed only by id. It also lacks the logic.isMounted() check that actionEditLogic has in its enabled callback.

Bug B — Cancel still discards: urlToAction in featureFlagLogic.ts calls actions.loadFeatureFlag() / actions.resetFeatureFlag() unconditionally on every method === 'PUSH'. None of those calls are guarded against hasUnsavedChanges. If any navigation reaches urlToAction even though the user clicked Cancel (the beforeUnload.onConfirm never ran), the form gets reset anyway and the edits are lost.

Suggested fix

1. Mirror the actionEditLogic.tsx tab-id / scene-cache guard (and the logic.isMounted() check) in the beforeUnload block of featureFlagLogic.ts.
2. Guard the loadFeatureFlag() / resetFeatureFlag() calls in urlToAction so they don't run while there are unsaved changes (or move the reset into beforeUnload.onConfirm so it only runs when the user actually confirms).
3. Add a regression test in featureFlagLogic.test.ts alongside the existing hasUnsavedChanges tests, asserting that cancelling navigation preserves the form values.

I'm happy to send a PR for this. Before I do — featureFlagLogic currently has no tabId on its props, so wiring the tab-id guard the way actionEditLogic does would mean adding tabId to FeatureFlagLogicProps + key() + the scene mount. Would you prefer that approach, or is there a lighter-touch fix you'd rather I take for Bug A?

Start with frontend/src/scenes/feature-flags/featureFlagLogic.ts and compare its beforeUnload handling with products/actions/frontend/logics/actionEditLogic.tsx. Read the existing hasUnsavedChanges tests in featureFlagLogic.test.ts, then verify that cancelling navigation keeps the form values and that the dialog does not prompt twice.