Gather every model under one tree at the repository root

The weights were in two places: face detection and recognition in
`models/face/`, segmentation in `core/dr-segment/models/`. Nothing was
wrong with either path, but between them there was nowhere to look to
answer "how much model does this application carry", and that number is
about to start growing.

So the crate-local copy moves up beside the other. `models/` now holds
`face/` and `segment/`, and a `du -sh` of one directory is the whole
answer.

No content changes: the .onnx and its vocabulary are byte-identical, and
`LICENCE.md` moves up a level to cover the tree rather than one crate.
The LFS pattern in `.gitattributes` is `*.onnx` and already matched both
locations, so only its comment needed the new path.

`include_bytes!` is relative to the source file and `build.rs` runs with
the crate root as its working directory, which is why the two paths climb
a different number of levels.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

models/LICENCE.md

@@ -0,0 +1,54 @@
+# Model weights — licensing
+
+`yolo26n-seg.onnx` is exported from Ultralytics YOLO26n-seg
+(`https://huggingface.co/Ultralytics/YOLO26`, `yolo26n-seg.pt`) by
+`tools/export-seg-model.sh`. `yolo26n-seg.classes.json` is that checkpoint's
+class vocabulary, written out by the same script.
+
+## The grant
+
+**Ultralytics releases YOLO under AGPL-3.0**, and the weights carry the same
+grant as the framework — the HuggingFace repository declares `agpl-3.0` for the
+checkpoints themselves, not merely for the training code. A commercial licence
+is offered separately; DarkRoom does not use it and does not need it.
+
+## What that means for DarkRoom
+
+DarkRoom is GPL-3.0-or-later. **GPLv3 §13 explicitly permits combination with
+AGPL-3.0 code**, so redistributing these weights inside this repository is
+allowed — this is *not* the situation the InsightFace "buffalo" weights would
+have created, where a non-commercial research grant is simply incompatible with
+the project's licence and with F-Droid, Flatpak and Play distribution
+(NFR-COMPAT-2, D13).
+
+The consequence, and it is a real one: **the combined work is effectively
+AGPL-3.0.** §13's permission runs one way — the AGPL's §13 network-use condition
+attaches to the portion under that licence. For a local-first desktop and
+Android photo editor that condition has no practical bite, because there is no
+network service offering the combined work to remote users. It would acquire
+bite the moment any hosted or server-side rendering appeared, and that is the
+thing to remember rather than rediscover.
+
+This was decided deliberately (D14), not arrived at by accident, and
+`docs/segmentation.md` §7 records the reasoning.
+
+## Class vocabulary — a caveat worth reading
+
+`docs/segmentation.md` §4 specified YOLO **pretrained on ADE20K**, whose 150
+classes include the *stuff* categories that matter most in photography — sky,
+vegetation, water, wall, mountain.
+
+**No such model exists in usable form.** Checked 2026-08-21: Ultralytics ships
+YOLO26-seg trained on **COCO**, whose 80 classes are all *things* — person,
+dog, car, bird, potted plant — and the one HuggingFace repository claiming a
+YOLO/ADE20K combination (`laxmacl/yolov8-ade20k`) is empty. ADE20K semantic
+models do exist, but as SegFormer/OneFormer/MaskFormer transformers, not YOLO.
+
+So the shipped vocabulary selects **subjects**, not **stuff**. "Select the
+person" works; "select the sky" does not come from the model and must come from
+the watershed hierarchy instead. That is a narrower arm B than §4 assumed, and
+it raises rather than lowers the importance of arm C.
+
+The loader treats the vocabulary as model metadata rather than compiled-in
+knowledge, so adding a stuff-class model later is a file plus a descriptor, not
+a code change.