Write the release notes, the permission answers, and the video

Play asks three separate things before a file manager may keep All files
access: the What's new copy, a justification for why SAF and MediaStore cannot
carry it, and a short video of the permission in use. Writing them exposed two
stale claims and one privacy problem, so those are fixed here rather than
repeated.

- docs/RELEASE_NOTES.md holds the Console field at 450/500 characters, measured,
  and the longer announcement. The first release's copy leads with the claim no
  competitor makes (no ads, no INTERNET permission) and then proves the app is
  still a file manager.

- docs/PLAY_RELEASE_CHECKLIST.md section 5 holds the declaration answer at
  490/500 characters. It argues from what the Storage Access Framework and
  MediaStore cannot do - one picked tree, no volume enumeration or whole-device
  hierarchy, no arbitrary non-media files - and never from performance, which
  Google's wording rejects. Both APIs are named as already used where they can
  be, so the argument is not that they are useless.

- docs/PERMISSION_VIDEO.md and store-assets/video hold a 19.7 s captioned video
  recorded on the release build. The home-screen segment is cut because its
  library counts are the owner's real totals; the published copy resumes on the
  internal-storage listing. Also recorded: the emulator captures one frame in
  three seconds, and only appops set --uid ... deny brings the prompt back after
  Settings has granted the app-op.

- README and ROADMAP caught up with the build: the status stopped at M15, and
  the trash limitation still said there was no Empty trash and that expiry
  waited for the next delete, both changed in M19.

Verified: ./tools/verify.sh green, the code map current, the Play field measured
at 450 characters and the form answer at 490, and the video decoded as H.264
1080x2400, 19.666 s, no audio, with frames checked at the cut and the end state.

CHANGELOG.md

@@ -12,6 +12,42 @@ upload needs a **higher `versionCode`** than every previous upload.
 
 ### Added
 
+- **The release notes exist before the release does, and their length is measured.** `docs/RELEASE_NOTES.md`
+  holds the copy for the Play Console's **What's new** field — **450 characters**, against Play's 500
+  limit, counted rather than estimated — plus a longer announcement for a website or GitHub release.
+  The Console field renders neither Markdown nor bullets, so the copy is plain sentences; the first
+  release's text leads with the claim the survey says no competitor makes (no ads, no `INTERNET`
+  permission) and then proves it is still a file manager, because "private" without the verbs reads as
+  a promise rather than a product. The file also says how the next one is written: move `[Unreleased]`
+  into a version heading **first**, so the changelog and the notes cannot describe different builds.
+
+  Two stale claims were found while writing it and fixed rather than repeated in the announcement: the
+  README's known limitations still said the trash had no "empty it now" action and that expiry waited
+  for the next delete (both changed in M19), and its status paragraph still stopped at M15.
+
+- **The Permissions Declaration Form's answer is written down, at 490 characters.** Section 5 of
+  [PLAY_RELEASE_CHECKLIST](docs/PLAY_RELEASE_CHECKLIST.md) now holds the justification for
+  `MANAGE_EXTERNAL_STORAGE`, measured against the form's 500-character field. It argues from what the
+  Storage Access Framework and `MediaStore` cannot do — a grant covers one picked tree, neither
+  enumerates volumes or presents a whole-device hierarchy, and `MediaStore` exposes media collections
+  rather than arbitrary files and folders — and never from speed, which Google's own wording rejects.
+  The app's existing SAF fallback and its single best-effort delete are named, so neither API is
+  dismissed as useless; it is only unable to carry the core purpose.
+
+- **The permission-use video is recorded, captioned and cut for privacy.** Play's form also asks for a
+  short video of the permission in use; `store-assets/video/permission-use.mp4` is **19.7 s** at
+  1080×2400 with six burned-in English captions (no audio), beside an uncaptioned twin and the `.srt`.
+  It shows the app's prompt, Android's grant screen (the phone's system UI is German, translated in the
+  captions), internal storage, non-media documents and a folder created through the same permission.
+  The raw take also showed the home screen, whose library counts are the owner's real totals, so the
+  published copy **cuts that segment** and resumes on the internal-storage listing. That is a privacy
+  redaction, not an edit to the evidence, and both copies share it.
+
+  Two traps are written down with it: the emulator under software emulation captures **one frame in
+  three seconds**, so the video has to come from the phone; and after Settings grants the app-op, a
+  package-level `appops set … deny` leaves the UID mode allowed, so only
+  `appops set --uid … deny` brings the prompt back.
+
 - **A dot marks what an operation just produced.** Copy something, extract an archive, rename a file or make a
   folder, and the rows it created carry a small dot until you open that folder again — so "what did that 4 GB
   copy do?" has an answer, including when the copy went to a folder you were not looking at. The mark lives in