docs: richer report — data figures, success/failure frames, commit-pinned repo links

- experiment_charts.py generates 4 figures from experiments/ artifacts:
  held-out per-film F1, 16-combo ranking, DE search landscape, and the
  Downton detector-vs-tracker ghost timeline (replaces the blank
  title-card screenshot)
- new frames: 19-correct wedding shot (success case), Many Saints
  ghost-vs-unknown frame (three error classes in one image)
- rename rep4-optimizer-results.md -> model-bakeoff.md; rep4 kept only
  as the on-disk artifact prefix, explained once
- repo file references are now links via https://REPOLINK/<path>
  placeholders; build_site.sh pins them to the HEAD commit's raw URLs
  and fails the build if a linked path doesn't exist at HEAD
- drop references to removed scripts (scene_score.py, score_config.py)
  and to session-memory names; mark artifact-registry paths with their
  pull commands
- commit readme_example.jpg + pipeline_topology.svg so README renders
  on the plain Gitea repo view
- deploy_pages.sh: push built site/ to the gitea-pages branch

docs/pose-expansion.md

@@ -1,6 +1,7 @@
 # Pose expansion: does "learning" new poses mid-film help?
 
-`expand_gallery` (`src/gallery/track_gallery.hpp`) promotes a confidently-identified
+`expand_gallery` ([`src/gallery/track_gallery.hpp`](https://REPOLINK/src/gallery/track_gallery.hpp))
+promotes a confidently-identified
 track's novel-pose reference views into a per-film, in-memory gallery annex — the
 idea being that once the pipeline is sure who someone is, a pose it hasn't seen
 before (turned head, different lighting) becomes a free extra reference for
@@ -21,8 +22,8 @@ Averaged across all 4 models, on the 4 films used for optimization:
 In `restricted` mode (matcher's candidate set capped to the film's own credited
 cast) expansion looked like a clean win: +1.8pp F1, +3.2pp recall, misID actually
 lower. In `full` mode it looked flat-to-costly: ~0 F1 change, recall +1.4pp, but
-misID roughly quadrupled (209 → 864) — see `rep4-optimizer-results.md` for the
-per-model breakdown. That's the number that motivated this page: **does turning
+misID roughly quadrupled (209 → 864) — see the
+[bake-off experiment log](model-bakeoff.md) for the per-model breakdown. That's the number that motivated this page: **does turning
 expansion on actually change what gets recognised, frame by frame, or is the
 aggregate F1 shift something else?**
 
@@ -83,7 +84,8 @@ mode) doesn't reproduce on held-out data — at minimum it's far smaller than th
 training-set numbers suggested, and plausibly it's sampling variation from only
 4 training films rather than a real, generalizable mechanism. This doesn't mean
 `expand_gallery` never does anything (the mechanism is real — see
-`track_gallery.hpp`'s promotion logging: tracks *do* get confirmed and views *do*
+[`track_gallery.hpp`](https://REPOLINK/src/gallery/track_gallery.hpp)'s
+promotion logging: tracks *do* get confirmed and views *do*
 get promoted into the annex on every film tested), only that **whatever effect
 it has on final per-second identification was too small to detect against 5
 held-out films** with this scoring method. A cleaner test would need either many
@@ -92,6 +94,7 @@ more held-out films or a metric that can see the annex's direct contribution
 pass had budget for.
 
 **Practical takeaway**: don't treat the training-set `exp` vs `noexp` numbers in
-`rep4-optimizer-results.md` as proof that expansion changes real-world behavior
+the [bake-off experiment log](model-bakeoff.md) as proof that expansion
+changes real-world behavior
 in either direction — on the evidence gathered so far, it doesn't move the
 needle enough to see.