Regenerate the spec and self-hosting pages; pin merged e2e main

flamenet-e2e!64 merged as 1eb2e4d, which carries the opaque TURN username
text. doc-pages failed because the generated pages still held the old text.

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

.e2e-ref

@@ -1 +1 @@
-c26cd74985dca5a961a70d5948ccecc5813dfad8
+1eb2e4d797eb3d0e9a25682f2c410d27bfc8df64

Resources/Views/self-hosting.leaf

@@ -3,7 +3,7 @@
 <!-- GENERATED by Scripts/build-doc-pages.sh from flamenet-e2e/SELF-HOSTING.md.
      Edits made HERE are deleted the next time that script runs.
      Change the markdown source and re-run it.
-     source-sha256: 1cf2f8cd9e0c7653 -->
+     source-sha256: 38f049224fdd009e -->
 <article class="band doc doc-generated">
   <div class="wrap wrap-narrow">
 <h1 id="self-hosting">Self-hosting</h1>
@@ -139,7 +139,11 @@ defaults:</p>
 </thead>
 <tbody>
 <tr>
-<td>Delivered envelopes</td>
+<td>Collected envelopes, on Postgres</td>
+<td>when the app's next poll confirms them</td>
+</tr>
+<tr>
+<td>Collected envelopes the app never confirms, or any on SQLite</td>
 <td>1 day</td>
 </tr>
 <tr>
@@ -158,7 +162,13 @@ defaults:</p>
 </table>
 <p>Override any of them with <code>FN_DELIVERED_RETENTION_DAYS</code>,
 <code>FN_UNDELIVERED_RETENTION_DAYS</code> and
-<code>FN_ATTACHMENT_RETENTION_DAYS</code>.</p>
+<code>FN_ATTACHMENT_RETENTION_DAYS</code>. Deleting on confirmation is
+<code>FN_DELETE_ON_ACK</code>, on by default; <code>0</code> turns it
+off. It never runs on SQLite, which reuses row ids, so the cursor there
+would delete the next message unread.</p>
+<p>None of this reaches your backups. A database dump or a WAL archive
+keeps what it captured for as long as you keep it, so your backup
+retention is part of your message retention.</p>
 <p>There is no unencrypted message store any more, so
 <code>FN_MESSAGE_RETENTION_DAYS</code> and
 <code>FN_READ_MESSAGE_RETENTION_DAYS</code> are not read. Setting them

Resources/Views/spec.leaf

@@ -3,7 +3,7 @@
 <!-- GENERATED by Scripts/build-doc-pages.sh from flamenet-e2e/docs/SPEC.md.
      Edits made HERE are deleted the next time that script runs.
      Change the markdown source and re-run it.
-     source-sha256: 7d3d71397adb1ff5 -->
+     source-sha256: 54ad3a70dc921dbe -->
 <article class="band doc doc-generated">
   <div class="wrap wrap-narrow">
 <h1 id="flamenet-messenger-end-to-end-encryption-spec">Flamenet
@@ -2123,12 +2123,16 @@ authenticates via the ratchet session.</p>
 <code>GET /e2e/turn</code>, TURN relay credentials</h3>
 <p>Mints time-limited credentials for the coturn relay using the
 standard REST-secret scheme
-(<code>username = &lt;unix expiry&gt;:&lt;user id&gt;</code>,
+(<code>username = &lt;unix expiry&gt;:&lt;opaque&gt;</code>,
 <code>credential = base64(HMAC-SHA1(secret, username))</code>). TTL 2
-hours. Response:</p>
+hours. The part after the colon is 32 random hex characters, fresh for
+every credential, and MUST NOT be the user id: the username crosses the
+network in clear in every STUN/TURN request, and coturn reads only the
+expiry before the colon. Clients MUST treat the username as opaque.
+Response:</p>
 <pre class="json"><code>{
   &quot;urls&quot;: [ &quot;stun:turn.flamenet.io:3478&quot;, &quot;turn:turn.flamenet.io:3478?transport=udp&quot; ],
-  &quot;username&quot;: &quot;1787260000:12&quot;,
+  &quot;username&quot;: &quot;1787260000:9f86d081884c7d659a2feaa0c55ad015&quot;,
   &quot;credential&quot;: &quot;&lt;b64&gt;&quot;,
   &quot;ttl&quot;: 7200
 }</code></pre>
@@ -3595,7 +3599,7 @@ status for §16 and §17</h2>
 <td><code>exportBackup</code> / <code>importBackup</code></td>
 <td>n/a, no server route, by design</td>
 <td>export and import, in Settings</td>
-<td>no</td>
+<td>export and import, in Settings</td>
 </tr>
 <tr>
 <td>§17 multi-device</td>
@@ -3614,11 +3618,20 @@ chat history…" and "Import chat history…", the file is sealed with a
 passphrase the person chooses, and <code>createBackup</code> has two
 call sites. Nothing continuous and no server copy, which is §16 as
 written rather than a lesser version of it.</p>
-<p>That is the third time this repository has understated iOS, after
-§15's two Android cells and §10's interop counts. All three were found
-the same way, by looking for the call site, and the rule holds in both
-directions: a cell is evidence about behaviour, and <code>no</code>
-needs checking exactly as hard as <code>yes</code>.</p>
+<p><strong>The Android cell read <code>no</code> until 2026-09-29, and
+had been wrong since 2026-08-28</strong> (<code>6a0f642</code> in
+flamenet-messenger-android). Settings has a
+<code>HistoryBackupSection</code> that exports and imports, through
+<code>MessengerViewModel.exportHistory</code> /
+<code>importHistory</code>, over the engine's <code>Backup.create</code>
+/ <code>Backup.open</code>, and <code>BackupVectorTest</code> checks
+that engine against <code>test/vectors/backup-v1.json</code> from this
+repository.</p>
+<p>That is the fourth time this repository has understated an app, after
+§15's two Android cells, §10's interop counts and the iOS cell above.
+All four were found the same way, by looking for the call site, and the
+rule holds in both directions: a cell is evidence about behaviour, and
+<code>no</code> needs checking exactly as hard as <code>yes</code>.</p>
 <p>§17 on iOS was checked at the same time and is correctly
 <code>no</code>: no device linking, no sent-copy handling, and no UI for
 either.</p>