This is necessary for an `RNode` to discover whether it is within the context of a shadow root, which is needed to know where a component's style should be placed.

The method is Baseline Widely Available, however we need to treat it as optional for SSR / JSDom contexts where shadow DOM is not supported.

…esHost`

When rendering components underneath shadow roots, it is possible to render multiple times, meaning `SharedStylesHost.prototype.addHost` will potentially be called multiple times on the same shadow root. This is reasonable, and we need to make sure that as long as any one component is still using a given shadow root as its host, we should continue applying styles there. Only when all usages of the host are removed do we stop adding styles to it.

This is useful for testing that `addHost` / `removeHost` were called the correct number of times to ensure hosts are not leaking.

…w roots

This updates component creation and view attach/detach to identify any containing shadow root and apply required styles to it. Managing this during attach / detach onto a view container seems like the ideal timing for what we need, since a node might theoretically be moved from one shadow root to another post-render. Awkwardly, `ViewEncapsulation.ShadowDom` / `ViewEncapsulation.IsolatedShadowDom` manage tracking of hosts already directly in `dom_renderer.ts`, and components should put their own styles in their own shadow root, not a containing shadow root. So we need to leave this alone for now and only modify the other `ViewEncapsulation` modes. A future refactor should consider unifying all `ViewEncapsulation` modes into a single code path.

This is quite inefficient as it adds all styles to all shadow roots, which is excessive and unnecessary. However precisely adding only the required styles is a more complicated refactor.

I initially tried to call `SharedStylesHost` via dependency injection, but found that injecting during component destruction does not work reliably, as the injector may already be destroyed. Instead, `SharedStylesHost` is tracked in the `LViewEnvironment` which works well as a single object reference shared amongst all components anyways.

…ter destruction

Since `SharedStylesHost` can receive `addHost` and `removeHost` calls after it is destroyed in testing environments (e.g., when fakeAsync triggers CD after teardown), we need to safely no-op these operations to avoid errors.

… `LViewEnvironment`

Prior to this change, when style encapsulation fell back from Shadow DOM, it defaulted to the global `document.head` via `getDocument()`. This was problematic for mocked or isolated environments (such as unit tests) where a custom `DOCUMENT` token is provided, but `setDocument` is not called. Because `SharedStylesHost` relies on the node it is passed, using the global `document.head` in a mocked environment could lead to cross-document DOM insertion errors or just failing to style the component correctly.

This commit introduces `fallbackDocument` to `LViewEnvironment`. It is captured at bootstrap in `createRootLViewEnvironment` directly from the `DOCUMENT` injection token, since we can't reliably inject during component destruction, falling back to `getDocument()`. This ensures that the correct document context is plumbed through the view layer, guaranteeing stable style injection inside the expected document environment without cross-document pollution.

This tests bootstrapping Angular underneath a shadow root and that styles are applied and removed at the correct locations.

…d on the injector

While developing this feature, I attempted to inject a service during component destruction (to call `SharedStylesHost.prototype.removeHost`), however this broke some Material use cases which seem to destroy the injector before the component. Whether this constraint was intended or not, I believe we currently live in a world where component destruction cannot depend on its injection, so I'm enforcing this in a test to be clear about that constraint.

This is not intended to imply that this is a _good_ constraint or that we _want_ this to be the case, but it does represent the reality we currently exist in.

…styles when re-adding a host in SharedStylesHost

`SharedStylesHost` has a known bug where removing hosts does not remove styles from the DOM and fixing that would be a breaking change. However, this leads to a separate bug where removing a style down to zero usages and then adding an extra one, could duplicate styles on the page. This ensures styles are only appended if they aren't already present on the parent node from a previously leaked style.