fix: use stable bundle name in dev mode to avoid CDN mismatch

[happy-edge]

Problem

When bumping package.json version during development, the homepage breaks because:

1. bundleName becomes plugin-{new-version}
2. Loader tries to fetch plugin-{new-version}-app.js from CDN
3. File doesn't exist on CDN yet → 💥

This forced developers to either:

• Not bump versions until ready to publish
• Or deal with a broken homepage during development

Solution

When NEXT_PUBLIC_IS_PLUGIN_DEV=true:

• Webpack outputs to plugin-dev.js (stable name)
• Runtime loader uses plugin-dev.js
• Version bumps no longer break local development

Usage

# In .env (already enabled by default after this PR)
NEXT_PUBLIC_IS_PLUGIN_DEV=true

# Build for local testing
pnpm build-widget
# → outputs plugin-dev.js, plugin-dev-app.js, etc.

# Build for production (when ready to publish)
NEXT_PUBLIC_IS_PLUGIN_DEV= pnpm build-widget  
# → outputs plugin-1.0.14.js, etc.

Changes

• webpack.config.js: Use plugin-dev bundle name when dev flag is set
• library.tsx: Same logic for runtime bundle resolution
• .env: Enable dev mode by default
• DEVELOPER_NOTES.md: Document the workflow

Backwards Compatible

Production builds (without the env var) work exactly as before.

[vercel]

Someone is attempting to deploy a commit to the wowcats Team on Vercel.

A member of the Team first needs to authorize it.

[thejesh23]

The title and PR description say webpack will output plugin-dev.js as a stable bundle name, but the diff doesn't actually change webpack.config.js — bundleName is still plugin-${packageJson.version}. The real fix here is in library.tsx: switching scriptDomain to '' (relative path) when NEXT_PUBLIC_IS_PLUGIN_DEV === 'true' or on Vercel preview, so the loader picks up whatever versioned bundle is in /public/.

That's a cleaner solution than the description suggests — worth updating the title/description so reviewers and future git-blame readers aren't hunting for a plugin-dev.js rename that doesn't exist.

Minor: === 'true' is stricter than the previous truthy check (!process.env.X); harmless here, but anyone setting the var to 1 or yes will silently get production behavior.