ImageSharp is not Apache-2.0 any more and nothing in the repo says what that means downstream

`Directory.Packages.props:36` pins `SixLabors.ImageSharp 3.1.12`. Since v3.0.0 that package is under the Six Labors Split License, not Apache-2.0.

The terms answer our case twice over. Apache-2.0 applies when the work is consumed "for use in software licensed under an Open Source or Source Available license", and separately when it is consumed "as a Transitive Package Dependency". barakoCMS is MPL-2.0, and every downstream user takes ImageSharp transitively through our package. A commercial licence is required only for a for-profit consumer at or above $1M annual revenue taking it as a *direct* dependency.

So there is nothing to fix in the code. There is something missing in the documentation.

## Why it matters

The people this product is aimed at are agencies shipping closed-source client sites. Some of them run compliance scans on their dependency tree, and a non-Apache licence on an image library is exactly the kind of hit that lands on a Friday.

Right now the answer to "do I need a Six Labors licence to use barakoCMS?" exists only in a licence file two hops away, and it has to be reconstructed by whoever is asked. That answer is "no, unless you also reference ImageSharp directly yourself" — worth writing down once, in our words, where a reader will find it.

The same shape applies to anything else we adopt with a split or revenue-threshold licence. QuestPDF, a candidate for #585, has exactly this structure. A short standing policy is cheaper than answering it per package.

## What to change

- A licence note in `docs/` — its own short page, or a section in the compliance posture doc — covering: what barakoCMS is licensed as, what that means for a closed-source consumer, and which dependencies carry terms that are not plain permissive.
- Name ImageSharp explicitly, quote the transitive-dependency clause, and state the direct-dependency threshold so a reader can check their own situation rather than trust ours.
- State the rule we apply when adopting new dependencies: a package reference must be permissive or transitively covered; anything copyleft is a container we talk to, never a reference we ship.

## What has to stay true

- This is documentation, not legal advice, and should say so.
- No dependency change. ImageSharp is fine where it is and the pin comment already explains why it was chosen over the libvips-based alternatives.

## Done when

- A reader can answer "does my closed-source commercial product need a Six Labors licence because of barakoCMS" from our docs alone.
- The dependency-adoption rule is written down where a contributor adding a `PackageVersion` will see it.

Found while surveying adjacent open source for integration candidates.

Start at Directory.Packages.props:36 and read the existing ImageSharp pin comment, then inspect docs/ for the compliance posture location or suitable new page. Document barakoCMS's licence, ImageSharp's transitive terms and direct-dependency threshold, the dependency-adoption rule, and the legal-advice disclaimer. Done when a closed-source commercial user can answer the licensing question from the docs and contributors can find the adoption rule.

Written by the indexing model from the issue text.