fix(createPlugin): defer factory call to install time to prevent resource leaks

[sridhar-3009]

Fixes #338

Problem

createXPlugin() (via createPluginContext) called the context factory at plugin-creation time — before app.use() ever runs:

// Before: factory runs here, at createXPlugin() call time
const [, provide, context] = createXContext({ ...options, namespace } as O)

This means:

• A plugin created but never installed allocates live resources (matchMedia listeners, watchers, unhead entries) that are never torn down
• Two plugin instances with the same namespace on one app: the second install is silently skipped, but its factory already ran and its resources are stranded
• useMediaQuery's hydration-deferral contract silently breaks on the plugin path — the factory runs outside any injection context

Solution

Move factory invocation inside the provide callback so it runs at install time, not factory time:

// After: factory deferred to install time
let context!: E

return createPlugin({
  namespace,
  provide: app => {
    const [, provide, ctx] = createXContext({ ...options, namespace } as O)
    context = ctx
    provide(context, app)
    // ...restore...
  },
  setup: app => {
    // context is set by provide, which always runs first
    config?.setup?.(context, app, options)
    // ...persist watch...
  },
})

provide always runs before setup (enforced by createPlugin), so the definite assignment is safe. The INSTALLED guard ensures setup never runs without a prior provide call.

createXContext (the standalone path) is unchanged — standalone contexts still create eagerly, which is correct.

Test plan

• 2 new tests verify factory is not called at createXPlugin() time
• All existing persist/restore ordering tests pass
• 6110 tests pass, typecheck and lint clean

[pkg-pr-new]

Open in StackBlitz

commit: d7e6f3c

[johnleider]

Pushed a small follow-up directly to this branch as a maintainer edit (d7e6f3c), on top of your fix.

What it addresses

The lazy-factory move is correct. One edge it left open is in setup, which still read the shared outer context binding. Now that the factory runs once per install, the same plugin object installed on more than one app reassigns context on each install — and the persist watch source closes over that mutable binding lazily, so a later install pulls the source out from under an earlier app's watcher.

Concretely: with a single createXPlugin({ persist: true }) object used on two apps, mutating app A's state ends up persisting app B's value into app A's storage key.

Fix is one capture — const ctx = context at the top of setup, used for both the config.setup call and the persist watch — so each app's watcher tracks the instance that provide created for it. The adapter path was already safe (it receives context as a parameter, a fresh per-call binding); only the in-createPluginContext persist watch needed it.

Tests added

• should not run a second factory when a duplicate namespace is installed — covers the issue's second scenario (a second same-namespace plugin object on one app must not run its factory).
• should persist each app independently when one plugin object is reused — fails against the shared-closure version ('b-initial' leaks into app A's storage) and passes after the capture.

Also

Trimmed the two inline comment blocks down to the why.

Verified in packages/0: vitest 23/23 on createPlugin, vue-tsc --noEmit clean, ESLint clean on both files.