feat(android): back text messages up, in a build Play does not get

A Messages section sends the SMS added since the last copy, as restorable
<smses> XML, into <folder>/<account>-messages/YYYY. A play flavor has neither
READ_SMS nor the code that reads messages; full is the default.

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

1 files changed, 31 insertions, 11 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 8293493..e733c7f 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -3424,11 +3424,13 @@ when told and the run carries on at the next opening.
 
 ### 9.13 Contacts and messages backup (Android)
 
-The Android application sends a copy of the phone's **contacts** to a folder of
-a group, on the photo backup's terms (§9.12): a client feature over the upload
-path, additive, once a day, the page doing the sending and the phone handing
-bytes over by token (`/phonesync/<token>`, `phonesync/` in the Android
-package, `phone-sync.js` on the page). Messages follow the same design.
+The Android application sends a copy of the phone's **contacts** and its **text
+messages** to a folder of a group, on the photo backup's terms (§9.12): a client
+feature over the upload path, additive, once a day, the page doing the sending
+and the phone handing one file over by token (`/phonesync/<token>`,
+`phonesync/` in the Android package, `phone-sync.js` on the page). Each kind is
+a `DocSource` that writes what is new since a marker; the marker moves only on
+the node's acknowledgement, so a file cut short is written again whole.
 
 **Where.** `<folder>/<account>-contacts/` of the destination every kind shares
 (§9.12), checked at every run the same way. Each copy is a new
@@ -3436,15 +3438,33 @@ file named for when it was taken (`contacts-2026-10-10-0900.vcf`), never a
 replacement: restoring is importing the newest one, and an older one is there
 if a phone sync went wrong.
 
-**What.** The whole address book as the platform exports it, one vCard per
+**Contacts.** The whole address book as the platform exports it, one vCard per
 contact through `ContactsContract.Contacts.CONTENT_VCARD_URI`, the format any
 phone imports. It is sent only when its SHA-256 differs from the last copy the
-node took; a day with no change sends nothing. The marker moves only on the
-node's acknowledgement, so a copy cut short is written again whole.
+node took; a day with no change sends nothing.
 
-**Unlike photos**, it runs on any network: a vCard file is small, and there is
-no first run of gigabytes to keep off mobile data. `READ_CONTACTS` is asked for
-when the person sets it up, never at start.
+**Messages.** `<folder>/<account>-messages/YYYY/sms-2026-10-10-0900.xml`: the
+SMS added since the last file the node took (the marker is the highest
+provider `_id` sent; ids only grow, so a message restored onto the phone later
+is sent too), the first file holding the whole history. The format is the
+`<smses>` XML that SMS backup applications restore, so a copy goes back onto a
+phone with tools that exist; `SmsXml.kt` writes it, keeping line breaks as
+character references and leaving out the characters XML 1.0 cannot carry.
+A contact name is filled in only when the person also allowed contacts. MMS
+are not included.
+
+**Two builds.** Play's policy gives `READ_SMS` to the default SMS application
+only, so the APK has a `store` dimension: `full`, distributed directly, and
+`play`, which has neither the permission (`src/full/AndroidManifest.xml`) nor
+the code that reads messages (`SmsSource.kt` is in `src/full`; `Flavor.kt`
+answers null in `src/play`). The bridge offers `messageSync` only where the
+shell has a message source (`MESSAGES` in its prelude), so the Play build shows
+no Messages section rather than one that refuses.
+
+**Unlike photos**, both run on any network: a contacts file is small, and a
+history of text messages is megabytes, not the gigabytes of a camera roll.
+`READ_CONTACTS` and `READ_SMS` are asked for when the person turns each on,
+never at start.
 
 ## 10. Filesystem portability