Put running the release build on a device into the checklist, and re-measure it

The R8 defect fixed in the previous change was invisible to every check that existed: it passed the whole unit suite, passed lint, and worked in the debug APK, and the release APK was the only thing that disagreed. Nothing in the process had ever run it. The checklist now has a section for that, placed with the artefact work rather than at the end, because the order in which the document is meant to be worked is build, run it, then declare things to Google. It carries the install commands (the release build is a separate package, so it can sit beside the debug one and be compared directly), the MIUI trap that a bare INSTALL_FAILED_USER_RESTRICTED means its dialog was answered late rather than that the APK is bad, the paths most worth walking (thumbnails, an operation long enough to show the notification, the two SQLite databases, each viewer, the FileProvider), a dumpsys check of what the installed build actually holds rather than what the APK declares, and the one instruction that matters when something differs - assume R8 removed something instead of assuming the feature is broken, because a class named only from a resource or reached only by reflection looks unused to a shrinker. A last item points the walk at the demo library from the screenshot section, so it is repeatable and a reviewer's own files stay out of it.

Renumbering meant fixing four references: two inside the checklist, and one each in STORE_LISTING (the screenshot section is now 7) and MONETISATION (pricing is now 8). A checklist that points at the wrong step is worse than one that points nowhere, so they were traced rather than assumed.

Section 3 also gets a fresh measurement, since its own rule is that a stale hash is worse than no hash because it reads as though it had been checked. The record it replaces was from 2026-10-15 and predated the library views, the duplicate finder and video thumbnails: the AAB is now 5 181 628 bytes (sha256 f053d90f...) and the APK 2 294 021 bytes (sha256 afe03dea...), both versionCode 1 / versionName 1.0.0 / targetSdk 36, with the permission set unchanged and still without INTERNET or any READ_MEDIA_*.

Two smaller repairs came out of the same pass. A link added in the previous commit pointed at EDGE_CASE_TESTING.md from the repository root, where it does not resolve - the changelog's other links all carry the docs/ prefix - and that was found by writing a link checker and running it over every relative link in the markdown: 37 of them, none now broken. And the re-measure warning had ended up stated twice, once per measurement record, so it now appears once, after the newest numbers and immediately before the upload steps.

Documentation only; no code changed, so the suite stands at 324 JVM tests and lint clean. The walk itself was done on the phone in the previous change - what is new is that the process now asks for it, which is the part that would have caught the defect in the first place.

CHANGELOG.md

@@ -157,6 +157,19 @@ upload needs a **higher `versionCode`** than every previous upload.
 
 ### Added
 
+- **The release checklist now has a step that runs the release build on a device.** The R8 defect
+  above was invisible to every check that existed: it passed the whole unit suite, passed lint, and
+  worked in the debug APK — the release APK was the only thing that disagreed, and nothing in the
+  process had ever run it. [docs/PLAY_RELEASE_CHECKLIST.md](docs/PLAY_RELEASE_CHECKLIST.md) § 4 is
+  that step: the install commands (the release build is a separate package, so it can sit beside the
+  debug one and be compared directly), the paths most likely to depend on something R8 cannot
+  see — thumbnails, the foreground service, the two SQLite databases, each viewer, the
+  `FileProvider` — and the one instruction that matters when something differs, which is to assume R8
+  removed something rather than that the feature is broken. Section 3 also carries a fresh
+  measurement of both artefacts (**AAB 5 181 628 bytes**, **APK 2 294 021 bytes**, both hashed),
+  because the previous record predated the library views, the duplicate finder and video thumbnails —
+  and a stale hash is worse than no hash, since it reads as if it had been checked.
+
 - **A video shows a frame of itself instead of a film-strip icon.** A phone holds more video than
   anything else, and a column of identical icons says nothing about which clip is which. Images and
   videos now take the same path — `EntryIcon` hands Coil the file, and for a video the request asks
@@ -253,8 +266,8 @@ upload needs a **higher `versionCode`** than every previous upload.
   Verified on the real phone: four genuine groups found among the device's own files — a ZIP
   duplicated across two folders, a PDF twice, another PDF three times — with the selection label
   reading "Delete 1 copy" and no crash in `logcat -b crash`. The *delete* was deliberately not
-  pressed on a device that is not mine to empty; [EDGE_CASE_TESTING](EDGE_CASE_TESTING.md) records
-  what was and was not exercised.
+  pressed on a device that is not mine to empty; [docs/EDGE_CASE_TESTING.md](docs/EDGE_CASE_TESTING.md)
+  records what was and was not exercised.
 
 - **A file inside an archive can be read without extracting it, and search can answer for the
   whole volume in one query instead of walking it.** Both were the obvious next question after