[Docs] Fix API reference

[adamziel]

Motivation for the change, related issues

Resolves a crash in the API reference that happened after the initial page hydration:

Implementation details

Problem 1 – CommonJS bundles from the TypeDoc plugin

docusaurus-plugin-typedoc-api ships its React components as CommonJS (module.exports = ApiPage). When Docusaurus’ ComponentCreator hydrates a page, it copies every enumerable export from the module onto the component. CommonJS functions still expose length, which is non‑writable, so the assignment throws Cannot assign to read only property 'length'.

Solution: Our wrapper plugin (packages/docs/site/plugins/typedoc-api-wrapper.js) intercepts the routes the TypeDoc plugin adds and swaps each component path for an ESM wrapper in packages/docs/site/src/typedoc/*.tsx. An ESM re‑export only exposes default, so ComponentCreator never tries to overwrite length and hydration succeeds.

Problem 2 – duplicate Docusaurus contexts

The TypeDoc plugin pulls its own copy of @docusaurus/plugin-content-docs (and friends). Webpack bundles that second copy, so components inside the API reference end up reading from a different React context than the one the rest of the site provides, leading to Hook useDocsPreferredVersionContext is called outside… errors.

Solution: packages/docs/site/plugins/docusaurus-dedupe-aliases.js walks each package’s exports map and tells Webpack to resolve every @docusaurus/* import to the single, hoisted version. With only one copy of the docs plugin, the contexts align and DocSearch/TypeDoc stop crashing.

Testing Instructions (or ideally a Blueprint)

This PR adds a dedicated Playwright config and test that builds the docs site, serves the static bundle, loads /wordpress-playground/api, and fails if hydration throws page or console errors. A new Nx target and CI job run the smoke test with Chromium so every PR proves the API docs render before we deploy.