Bug: Hydration mismatch error for HTML entities in direct text children of <noscript> tag

React version: 18.2.0

Steps To Reproduce

In a React SSR app, include a <noscript JSX element with text children that contains an HTML entity, such as ':
```
export default function App() {
  return <noscript>&apos;</noscript>;
}
```
Render the React app on the server using ReactDOMServer.renderToString (no visible warnings appear):
```
const component = ReactDOMServer.renderToString(<App />);
```
Of note, this appears to replace the HTML entity in final HTML output with a different entity:
```
...<noscript>&#x27;</noscript>...
```
Attempt to hydrate the React app on the client using hydrateRoot:
```
hydrateRoot(document.getElementById("root"), <App />);
```
UI mismatch error occurs at hydration time

Link to code example: https://github.com/jazeved0/react-ssr-noscript-bug-reprod (steps to build/run are in the readme)

The current behavior

Using an HTML entity in the direct text children of a <noscript> tag results in hydration errors on the client. I encountered this while building a Gatsby static site where I wanted to include a <noscript>-wrapped warning in a component that only works when JavaScript is enabled (and this message includes an apostrophe character).

The following cases encounter the same/a similar error:

Same example as above (and the one I originally encountered):
```
<noscript>&apos;</noscript>
```
Using the direct character:
```
<noscript>'</noscript>
```
Using the other HTML entity that React SSR uses, in the original source of the component:
```
<noscript>&#x27;</noscript>
```

The following cases do work:

Wrapping the text containing the HTML entity in a plain <div>, inside the <noscript>:
```
<noscript><div>&apos;</div></noscript>
```

Using dangerouslySetInnerHTML:

<noscript dangerouslySetInnerHTML={{ __html: "&apos;" }} />

The expected behavior

All of the above cases (except wrapping the HTML entity in a <div>) should result in the same behavior, and exhibit no errors when hydrating on the client.

I believe this may be related to https://github.com/facebook/react/issues/11423 (although notably the behavior of "ignore

facebook / react