docs: EventSaver has no compiled-in folder fallback any more

The adoption guide told an adopting site that a missing EventSaver.ini makes
the binary fall back to "the reference site's file server". That was true of
EventSaver.cs until the ADR-015 fix set Folder to empty, and EVENTSAVER.md was
updated then while this page was not, so the two documents disagreed about what
a missing ini does.

Current behaviour is that it shows nothing, which is the point: failing visibly
beats displaying another site's slides. Says that, and adds the case the old
text was accidentally describing - a .scr compiled before the fix still carries
the path, so a binary somebody was handed is not the same as one they built.

Scope: product

docs/ADOPTING-AT-ANOTHER-SITE.md

@@ -275,10 +275,17 @@ showing the last set instead of going black.
 
 ### The two things that catch people out
 
-**The compiled-in fallback is not yours.** If `EventSaver.ini` is missing or
+**There is no compiled-in fallback - ship the ini.** If `EventSaver.ini` is
-both `url` and `folder` are blank, the binary falls back to a folder path
+missing, or both `url` and `folder` are blank, EventSaver has no source to read
-compiled into `EventSaver.cs`, which is the reference site's file server. Ship
+and shows nothing. That is deliberate: the source used to carry the reference
-the ini. A missing ini is not a neutral default.
+site's file server as its default `Folder`, so a missing ini silently pointed a
+new site at someone else's share. It is empty now (ADR-015), and failing
+visibly beats displaying another site's slides.
+
+Check any binary you were handed rather than built. A `.scr` compiled before
+2026-08-18 still has that path baked in, and it will use it the moment the ini
+goes missing. Build from the source in `plugins/slides/client/` - see BUILD
+instructions in [EVENTSAVER.md](EVENTSAVER.md).
 
 **If you enforce the ini by hash, your own edits revert.** The reference
 manifest pins `EventSaver.ini` with `DetectionMethod: Hash`, which is what makes