Record why shape binding uses ldp:constrainedBy and not ShapeTrees

[tophcodes]

What

Record why shape binding uses ldp:constrainedBy rather than ShapeTrees, or change it.

Why

In LDP 4.2.1.6 ldp:constrainedBy is a Link relation a server publishes on failure, pointing at a constraints document that is explicitly allowed to be human-readable prose. This pod additionally reads it as a machine-readable binding written by the client into a container's own graph. That is a reasonable overload and it is still an overload.

Solid has a competing answer in ShapeTrees, and a spec-literate reader will ask why not that
one. The answer may well be good: ShapeTrees is heavier, it is not in the Solid Protocol,
and it brings a hierarchy model this pod has no use for. But the answer is currently
nowhere, so the choice reads as unconsidered rather than decided.

This is the shape of thing docs/decisions.md exists for: deliberately looser than the specification it follows, and getting it wrong is silent.

How

• Write it as an ADR, or change the mechanism. Both are fine; leaving it undocumented is not.
• Whichever way it goes, say whether the LDP-required behaviour is also present: a constrainedBy link on the 422, because that part is what LDP asks for and it is easy to lose while arguing about the rest.