docs: finish the Console pre-flight and retire the screenshot blocker

Everything the Play forms ask for that can be settled from the working copy, settled:

- PRIVACY.md now carries the real contact address (softwareapp.hb@gmail.com), so the
  policy publishes as-is. Hosting is the one step left that cannot be done from here,
  because the repo has no git remote: step 5 of the checklist spells out the push +
  GitHub Pages route and the URL it yields.
- Checklist: the screenshot item is done (four captures, 1080x2160, over the demo
  library, no permission banner), the keystore and versionCode are recorded as already
  in place - including the upload key's SHA-256 for the Play App Signing enrolment - and
  the App access / Ads / remaining App content declarations are written down. The
  first-upload release-notes question is answered too: versionCode is already 2, so
  1.0.1 takes the *initial release* block, not the 1.0.1 one.
- The build facts were verified against the artefacts rather than the source: the
  release APK reports versionCode=2, versionName=1.0.1, targetSdk=36 and exactly the
  documented permission set, with no INTERNET in what actually ships.
- ROADMAP: the re-shoot row is struck out with the numbers that closed it, M10 no longer
  claims the captures predate the demo library, and the demo library's removal is
  recorded (MediaStore 5,386 -> 5,364; pruneTo drops the stale index rows next scan).

The staged state and the system confirmation dialog are documented as deliberately not
captured: staging clears the demo group, which would put real photos back in frame.

docs/STORE_LISTING.md

@@ -132,15 +132,21 @@ adb shell rm -rf /sdcard/DCIM/foto-dup-demo
 adb shell content call --uri content://media --method scan_file --arg /sdcard/DCIM/foto-dup-demo
 ```
 
-Two more screens are worth adding to the set. Each needs a tap, and MIUI only accepts taps from a
-human, so they are captured by hand — a loop that takes a `uiautomator dump` and screencaps whenever
-the UI **text** changes is enough, so the capture never depends on tap timing. That is how
-`04-options.png` was taken, and it catches the menu, the staging and a system dialog in one pass:
+This was run on the test device as soon as the four captures were taken: MediaStore went from
+**5,386 to 5,364** image rows and the 22 demo rows are gone. The matching rows in the app's own
+hash index are dropped by `PhotoIndexStore.pruneTo` on the next scan — the index is keyed by
+MediaStore id, so there is nothing else to reset.
 
-- the staged state (*“All duplicates are ready to go”*) after *Remove all selected*. Nothing is
-  deleted at that point and no dialog appears yet — the rows simply leave the list.
-- Android's **confirmation dialog** for the whole batch, which *Apply* launches. Dismissing it is
-  non-destructive: the staging is kept, and *Apply* can be tapped again.
+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.)
+
+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
+enough, so the capture never depends on tap timing; that is how `04-options.png` was taken.
 
 ## Store listing copy
 
@@ -212,5 +218,5 @@ in `app/build.gradle.kts`, and the second-run speed-up is the persistent hash in
 - **Category:** Tools (alternative: Photography — *Tools* matches the one-job utility framing
   better, and Photography is more crowded).
 - **Tags:** duplicate photos, photo cleanup, storage.
-- **Contact details:** the same e-mail as in [PRIVACY.md](../PRIVACY.md) — replace the
-  `support@example.com` placeholder there first.
+- **Contact details:** `softwareapp.hb@gmail.com` — the same address as in
+  [PRIVACY.md](../PRIVACY.md), so the policy can be hosted as-is.