[Bug]: react-storybook-addon-export-to-sandbox never finds its own registration on Windows

[ArrayKnight]

Area

storybook

Environment

OS: Windows 11
node v22.12.0
@fluentui/react-storybook-addon-export-to-sandbox 0.3.1

Current Behavior

packages/react-components/react-storybook-addon-export-to-sandbox/src/webpack.ts locates its own
registration by matching the registered preset name against:

const addonFilePattern = /react-storybook-addon-export-to-sandbox\/[a-z/]+.[jt]s$/;

The pattern accepts forward slashes only. On Windows the registered preset name is an absolute
path with backslashes (e.g. …\react-storybook-addon-export-to-sandbox\temp\preset.ts), so the
pattern matches nothing. The addon options are then silently dropped, and the full-source babel
plugin crashes downstream on an undefined importMappings.

The failure is platform-specific and silent right up to the crash: on Linux CI nothing has ever been
wrong, which is why it has survived.

Expected Behavior

The addon finds its registration and receives its options on every platform the repo supports for
local development.

Reproduction

Run any Storybook in this repo that registers the addon, on Windows. The branch demonstrating both
the failure and the fix is available on request.

Steps to reproduce

1. On Windows, yarn start a Storybook target that registers
   @fluentui/react-storybook-addon-export-to-sandbox.
2. Observe the full-source babel plugin throwing on undefined importMappings.
3. Instrument addonFilePattern — it matches nothing, because the preset name is backslash-separated.

Discovery context

Found while standing up a new Storybook target on a Windows checkout during work on a styling layer
over @fluentui/react-headless-components-preview. Nothing about the finding is specific to that
work — any contributor developing on Windows hits it the first time they run a Storybook that
registers this addon.

Proposed fix

Accept either separator:

const addonFilePattern = /react-storybook-addon-export-to-sandbox[\\/][a-z\\/]+.[jt]s$/;

One line, with a comment explaining why both separators are there so it is not "tidied" back.

A working implementation is included in PR #[WINDMOD-PR-NUMBER] (part of commit 510b8c5d21);
happy to split it into a standalone PR against this issue — it is genuinely independent of
everything else in that PR.

Suggested severity

Medium - Has workaround (develop on Linux/WSL, or disable the addon).

Products/sites affected

Local Storybook development on Windows.

Are you willing to submit a PR to fix?

yes