Prevent repeated preview re-renders with async Shiki highlighting

[tnhu]

Summary by cubic

Fixes the shiki syntax highlighting re-render loop by making onChange fire only on real content changes and updating docs/examples to use guarded, cached async highlighting. Editors stay stable while highlights load; distribution files are restored.

• Bug Fixes

  • Centralized _notifyChange(); onChange now fires on input and when setValue actually changes content, not during render; safe to call updatePreview() inside onChange.
  • Shiki docs/example use full-code cache keys with a pendingHighlights guard; switched to editor.setCodeHighlighter and editor.updatePreview() to avoid feedback loops.
  • Added tests for single-fire on setValue, ignoring render-only updates, and non-recursive preview refresh.

• Refactors

  • Restored dist/* for distribution.
  • README updated to reflect ~117KB size.

^{Written for commit 9035858. Summary will update on new commits.}

[panphora]

Merged in 35d93fd via cherry-pick (rebuilt dist/ locally rather than carrying it in the merge). Original commits and authorship by @tnhu preserved on the resulting commit.

Thanks for the fix — this is a real footgun for anyone wiring up Shiki, and the change to _notifyChange() is the right place for it.

Will ship in the next release.

[panphora]

Shipped in v2.3.7 (commit 35d93fd).

Centralized change notification behind _notifyChange() and only fire it on real content changes (input events and setValue() with a different value), not on every updatePreview(). Updated the Shiki docs example to use a pendingHighlights guard and editor.updatePreview() for the refresh, eliminating both sources of recursion.

Thanks @tnhu for the fix and the test cases.