feat(android): back the videos of the chosen albums up beside the photos

A 'Videos too' option, off by default, sends them into the same YYYY/YYYY-MM
folders. Files are read from the phone a ranged chunk at a time, so a large
video is never whole in the page.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 16 insertions, 3 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index a30215d..5ba1980 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -3414,10 +3414,23 @@ the edit is sent **beside the original**, as `<stem>-edited-<YYYYMMDD-HHMMSS>.<e
 from the edit's date. A touch that left the bytes alone sends nothing. "Save as
 copy" makes a new photo and needs no rule.
 
+**Videos.** Off by default, ticked in the same section: the videos of the
+chosen albums (a MediaStore bucket holds both, under one id) go beside the
+photos, in the same `YYYY/YYYY-MM` folders, under the same ledger, rules and
+unmetered network. `READ_MEDIA_VIDEO` is asked for when they are ticked in.
+The confirmation states the videos' count and size apart, because they are
+most of it. A file is never whole in the page: the upload reads it a chunk at
+a time and each chunk is a ranged request to the phone (`Range: bytes=a-b`,
+answered 206 by `ByteRange.kt`), so a video of gigabytes costs the WebView one
+chunk of memory; the SHA-256 the ledger keeps is then read from the phone once
+the node has the file. The Photos tab does not show videos yet; Files does.
+
 **Location.** The manifest does not ask for `ACCESS_MEDIA_LOCATION`, so a
-photo read through MediaStore has its EXIF location **redacted by the
-platform**: a camera roll going to a group does not say where its owner lives,
-and nobody had to do anything for it.
+photo or video read through MediaStore has its location **redacted by the
+platform** (Android 10+): a photo's EXIF, and in an MP4 or MOV the location
+boxes MediaProvider finds (`IsoInterface`). A camera roll going to a group
+does not say where its owner lives, and nobody had to do anything for it. On
+Android 8 and 9 nothing redacts it.
 
 **Refusals.** A refusal that will hold tomorrow — `disk_full` (§6.4), a folder
 no longer writable, gone or on a drive that is not plugged, the member removed