docs: follow the asset publication through the documents that described it

Committing the store assets changed a rule that four files stated, so they now state the new one
instead of contradicting the tree:

- STORE_LISTING: "screenshots are not committed" becomes what is committed, why it is safe (every
  published frame is generated demo content), and what is still deliberately out of git (raw
  captures, demo photos, the video's milestone PNGs). It also spells out the public URL pattern,
  because that is now the deployment step rather than a footnote.
- PLAY_RELEASE_CHECKLIST: the two "(git-ignored)" annotations on the screenshot directories become
  "(committed)", and step 5's video item carries the exact link to paste plus what was verified
  about it (200, video/mp4, Content-Disposition: inline, sha256 match) and the two traps in using
  it (pinned to main, so a re-shoot overwrites in place; and replacing it at all means resubmitting
  the declaration).
- ROADMAP: M10 no longer claims the screenshots are left uncommitted, and the declaration's blocker
  row loses its "hosting remains" clause - the file is published, so only pasting is left.
- README: says where the link comes from, so the next reader does not go looking for a host.

docs/STORE_LISTING.md

@@ -9,12 +9,19 @@ release.
 
 ## Graphics
 
-Generated into `store-assets/` **inside the repository**, never into `$HOME`. The icon and the
-feature graphic are the files that get uploaded to the Play Console, so they are committed and
-versioned with the release they belong to. **Screenshots are not committed** — neither the raw
-captures (`store-assets/raw-screenshots/`) nor the normalised ones (`store-assets/screenshots/`) —
-because a screenshot of this app is a picture of a photo library. Regenerate them with the
-commands below and upload them straight from disk.
+Generated into `store-assets/` **inside the repository**, never into `$HOME`, and **committed**:
+the icon, the feature graphic, the twelve normalised screenshots and the foreground-service
+demonstration video all live in git, versioned with the release they belong to. That is deliberate
+— Play wants a *link* to the demonstration video, so an asset has to be reachable without a login,
+and once one is, it is simpler to keep the whole listing beside the code that produces it.
+
+Publishing them is safe because of where they are shot: every published frame contains the
+**generated** demo library and nothing else (`tools/make-demo-photos.py`), so the screenshots show
+the app *over* that library. The phone set was re-checked frame by frame before publication; the
+sole trace of the test device's own 5,385-photo library in it is a count in the summary card. What
+stays out of git is the scratch around them — the raw `adb` captures
+(`store-assets/raw-screenshots/`), the demo photos themselves, and the recording script's milestone
+PNGs. Regenerate any of it with the commands below and upload straight from disk.
 
 Screenshots live **one directory per form factor**, because Play gives phones, 7-inch tablets and
 10-inch tablets a slot each (`Main store listing` › *Graphics* › *Phone* / *7-inch tablet* /
@@ -22,7 +29,7 @@ Screenshots live **one directory per form factor**, because Play gives phones, 7
 
 ```
 store-assets/raw-screenshots/{phone,tablet-7in,tablet-10in}/   git-ignored `adb` captures
-store-assets/screenshots/{phone,tablet-7in,tablet-10in}/       the files that get uploaded
+store-assets/screenshots/{phone,tablet-7in,tablet-10in}/       the files that get uploaded — committed
 ```
 
 ```bash
@@ -33,6 +40,18 @@ FORM_FACTOR=tablet-10in ./tools/make-store-screenshots.sh   # 10-inch -> screens
 python3 tools/make-demo-photos.py                           # synthetic photo library -> demo-photos/ (git-ignored)
 ```
 
+Committing `store-assets/` is also what *publishes* it: Gitea serves every committed file without a
+login, at
+
+```
+https://gitea.softwareapp-hb.de/fishfacegit/foto-duplicate-finder/raw/branch/main/<path>
+```
+
+so pushing the commit **is** the deployment step — there is no separate upload, and a re-shot
+screenshot or re-recorded video goes live as soon as it is pushed. Play's foreground-service
+declaration takes its video link from exactly there; the URL is written out in
+[PLAY_RELEASE_CHECKLIST](PLAY_RELEASE_CHECKLIST.md) step 5.
+
 | Asset | Play's spec | Result | Source |
 |---|---|---|---|
 | App icon | 512×512, 32-bit PNG with alpha, ≤ 1 MB | `store-assets/icon-512.png` — 512×512, RGBA, 6 KB | `tools/store-assets/icon.svg`, mirrored from `app/src/main/res/drawable/ic_launcher_background.xml` + `ic_launcher_foreground.xml` (paths and group transforms are identical, so the store icon *is* the launcher icon) |
@@ -258,9 +277,8 @@ MediaStore id, so there is nothing else to reset.
 Two further screens were weighed up and deliberately left out of the set: the staged state (*“All
 duplicates are ready to go”*) after *Remove all selected*, and Android's confirmation dialog for the
 batch that *Apply* launches. Staging every selected row also clears the demo group out of the list,
-which promotes the device's own 39.8 MB group into frame — so those captures could not be published,
-and since screenshots are not committed there would be nothing to keep them for. (Dismissing the
-dialog is non-destructive, so nothing is lost by not going that far.)
+which promotes the device's own 39.8 MB group into frame — so those captures could not be committed
+or published. (Dismissing the dialog is non-destructive, so nothing is lost by not going that far.)
 
 Captures are taken by hand, because each of these screens needs a tap and MIUI only accepts taps from
 a human. A loop that takes a `uiautomator dump` and screencaps whenever the UI **text** changes is