Description

React 19 has several behavior changes to StrictMode that could easily be thought to be bugs in either React or Lexical but at this point it seems that all cases are "simply" user error. This PR takes the following approach to mitigate this potential issue:

• Use the React 17+ automatic JSX runtime (required for React 19, this was merged in [lexical-react] Breaking change: Deprecate public default exports #6088)
• Modernize Lexical code, tests, and doc examples to be (hopefully) correct and warning-free with React 18 and 19 (based on a thorough reading of the React 19 Upgrade Guide) - some of this was cleaning up existing tests to be more correct, not necessarily React 19 related but important for validation. No codemods were run, the only large change was to the tests (adding an act shim), the codemod wouldn't have helped us in a React 18 compatible way.
• Change CI workflow to run a full set of the unit and e2e tests in CI with React 19
• New tests to validate our expectations of how React should interact with Lexical (both in and out of StrictMode)
• New documentation covering @lexical/react best practices, and common mistakes that can be made with useEffect that surface under StrictMode (which are usually real bugs in concurrent mode and/or suspense that are hard to reproduce otherwise)
• Workaround for vite config so that the playground builds with React 19

Other inclusions:

• Fix up some overlapping names in package.json files
• Fix all unit test warnings (including silencing ArtificialNode__DO_NOT_USE warning in __DEV__ everywhere), audit @ts-ignore usage and remove unnecessary usage
• Fix a window mutation leak in one of the unit tests (updated queueMicrotask without restoration)
• Updates TypeScript because we were installing two versions (one for lexical-devtools and one elsewhere)
• Moves integration tests behind extended-tests label

NOTE: @lexical/react does claim compatibility with react >=17.x in its peerDependencies but only ^18.2.0 and beta are tested as of this PR. It would probably be a better use of resources to raise the bar to >=18.x (or just leave it as-is until someone tells us it is broken) than to test further backwards, unless there are significant users that are stuck on 17.x for some reason.

Closes: #6044
Closes: #6126
Closes: #6132
Closes: #5911

Test plan

Before

• The tests had some hard to debug warnings (due to microtask concurrency and in one case just a partially broken test) with any version of React
• We had no automated way of confirming that everything works with React 19
• Users would commonly run into tricky StrictMode issues that typically required expert help to diagnose

After

• All tests pass without warning in React 18 and 19
• CI confirm that everything works with React 18 and React 19 (technically not 19, but whichever react and react-dom versions are tagged beta at the time of CI)
• Users will probably have the same issues, but we'll have some documentation to point them to

Follow-up Considerations

We could help mitigate more user issues by:

• More aggressively detecting common pitfalls with __DEV__ warnings or invariants (e.g. write a hook that gets eliminated in prod that warns if a particular argument does not have a stable identity)
• Adding lint rules to @lexical/eslint. A class of lint rule that would be useful in this scenario would be detecting functions without stable identity (useCallback, useMemo, useRef, etc. or being defined out of component scope) that are passed as component props or hook arguments that would be problematic like CollaborationPlugin providerFactory or useLexicalSubscription