Reuse the mounted plugin when simulating a remount

A Streamdown remount does not execute the module again, so markdown-text.tsx continues passing the same module-scoped plugin object and its slotsByKey cache. Creating a fresh plugin here instead tests the unrelated implementation detail that @streamdown/code caches tokenization across plugin instances; if upstream safely moves that cache into each plugin instance, actual remounts remain synchronous but this test fails and blocks the upgrade. The remount assertion should call the already mounted plugin, while the separate scope test ensures that object survives.

Useful? React with 👍 / 👎.

Confirmed, and the check is stronger than it looks. A remount rebuilds the component tree, not the module, so markdown-text.tsx keeps handing Streamdown the same module-scope plugin. Building a fresh wrapper here meant the synchronous answer came from the module-scope caches inside @streamdown/code rather than from our own fence slots.

Measured both directions on the tree at 514d411:

• Moving createCodePlugin inside MarkdownTextImpl, which is the exact regression this test's failure message describes, left this test green. Only the module-scope walker caught it.
• Patching @streamdown/code so its caches are per-instance, which is a change upstream could make safely, turned this test red while production stayed synchronous.

So it was failing on a healthy tree and passing on a broken one. Fixed in 1b686c3 by reusing the mounted plugin.

Distinguish module initialization from function syntax

This treats every call lexically contained in a function as runtime component construction. For example, extracting the current setup into function buildCodePlugin() { return createCodePlugin(...); } and invoking buildCodePlugin() once in the module initializer still preserves the plugin across every remount, but this walker reports the inner call as non-module-scoped and fails the test. Check where the factory is invoked rather than merely whether the constructor expression appears inside any function.

Useful? React with 👍 / 👎.

The scenario is real and I reproduced it: a helper invoked at module init preserves the plugin across remounts, and the walker still fails it. Keeping the walker as is.

It has no false negative, which is the property that matters here. Moving the call inside MarkdownTextImpl goes red, and adding a second module-scope build goes red on the count assertion. The only cost is a misleading message on a refactor nobody is proposing, and teaching the walker call-graph reachability to cover it is machinery for a case that does not exist.

Tie the threshold assertion to the production value

When MIN_INCREMENTAL_CHARS in code-plugin.ts is increased beyond this fixture's length, this independent copy remains 2000, so the assertion still passes while highlight takes the small-fence shortcut. The test would then stop exercising the per-fence slot path and could miss the wrapper regression it is intended to pin; derive the boundary from production code or construct the fixture so the exercised path is verified directly.

Useful? React with 👍 / 👎.

Confirmed, and it was hiding a real gap. The assertion compared against a local copy of the constant, so on the tree at 514d411 I raised MIN_INCREMENTAL_CHARS in code-plugin.ts to 100000 and every one of the four highlight calls took the small-fence shortcut instead of the slot path, with both tests still green. The test silently stopped covering the path its own comment says it covers.

Fixed in 1b686c3: the constant is exported and imported. The same break now fails with "the fixture fence dropped below the incremental threshold, so this test no longer covers the slot path".