Guidelines on when (not) to imperatively update DOM

Nobody has claimed this yet.

The question came up 2x today in Lit&Friends slack: When is it ok to update lit-managed DOM imperatively?

Like, this is ok:
```js
#charts = new SomeCleverDomCharts();
firstUpdated() {
this.#shadowContainer = this.renderRoot.querySelector('.container');
this.#charts.mount(this.#shadowContainer);
}
```
because lit won't be updating `#shadowContainer`'s child tree

but in a case like:

```js
render() { return html`

` }
updated(changed) {
if (changed.has('expanded') {
this.#shadowContainer.classList.toggle('expanded', this.expanded);
}
}
```
That's ok *only* if lit will *never* update the class, right?
or we could say the same with an svg use case:
```js
render() {
return html`

`;
}
```

-----

So it would be nice to have a page to point to with instructions on *what* will lead to breakage (updating DOM that's already managed) and what's perhaps a matter of "best practice" (preferring to do it in the template)

Review the imperative DOM and SVG examples in the issue, then identify the documentation page or entry point where guidance on Lit-managed DOM belongs. Define the page around when imperative updates are safe, what causes breakage, and when template updates are preferred; it is done when these cases are explained clearly with the issue's examples.

Written by the indexing model from the issue text.