Require servers to prevent or sanitise HTML on write by default for unauthenticated users

This issue complements #514, which focuses on serving html rather than writing of HTML. It also follows up on an implementation specific issue raised on https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1596

The spec allows constraints to be specified (https://solidproject.org/TR/protocol#constraints-problem-details) but as far as I can tell does not currently require any constraints

At the moment the spec does not appear to prevent writing of HTML to a server by unauthenticated users in cases where public write or append permission has been granted.

Such permission is a useful part of an inbox, so it looks like this an issue for the LDN specification as well, but applies generally to writing to a server.

I believe a minimum requirement is for the spec to require that a server use constraints that by default prevent or sanitise executable code on write for unauthenticated users.

A stronger version would be that a server MUST apply security constraints to any resource exposed to write and append permissions by unauthenticated users.

Out of the box, we don't want to allow accumulation of spam documents with possible security risks, regardless of how their risk is mitigated when served or on the client side.

Depending on interpretation, this possibly also has implications for the question:
"Do features in this specification enable new script execution/loading mechanisms?"

Arguably the spec does enable new mechanisms for loading scripts into a server, and therefore into a privileged context from which new attack surfaces are possible.

If this issue is already somehow covered by the spec, it would be useful for the mitigation to be summarised in this or another security question.

Read the Solid Protocol constraints problem-details section, then compare this issue with #514, #1596, and the LDN specification. Determine whether the specifications already cover unauthenticated write and append constraints; done means a clear normative requirement or a documented security mitigation, including the script-execution question.