build the app, and ship it on Linux and Windows as well as macOS

The client itself: the sync engine and mirror, the Gmail and IMAP providers,
the screener, the three boxes and two piles, compose and send, the sanitiser
and tracker stripping, contacts, clips, backup, notifications and the guide.

The pipeline that ships it. Three runners now build in parallel and the
publish gate wants all four platform keys in latest.json before a release
leaves draft. Linux gets two more packages Tauri does not build: a flatpak
repackaged from the deb against GNOME 48, and a Nix package that relinks the
deb against nixpkgs so it runs as a native Wayland client rather than through
Xwayland. CI runs the Rust suite on all three desktops rather than on Linux
alone, and rebuilds the flatpak manifest on every push to main.

Two things that were only ever exercised on macOS and were wrong everywhere
else. The menu bar was built by adjusting the submenus macOS is given, so on
a platform whose default menu has no File or View the new File menu landed
after Edit, Check for Updates landed nowhere, and the three places and the
reading pane had no menu at all. The deb declared libwebkit2gtk-4.1-0 and
libgtk-3-0 twice, because tauri.conf.json named the dependencies Tauri
already emits.

The updater key exists now, so releases can sign their artifacts.

src-tauri/src/backup/store.rs

@@ -0,0 +1,30 @@
+// Three operations, and the reason there are only three.
+//
+// A journal segment is a whole blob written once under a name that never changes meaning, so
+// nothing above this trait needs a rename, a delete, a directory, a lock, a range read or a
+// conditional write. What is left is put, get and list, which is the intersection of Drive's REST
+// API and S3, and small enough that the second implementation was an afternoon and the one in
+// `tests.rs` is thirty lines. A backup whose store trait needs a transaction is a backup that
+// cannot be pointed at somebody's own bucket.
+//
+// A name is a path with forward slashes: `<account-hash>/<device-id>/<first>-<last>.seg`. Drive
+// has no paths, so it maps them onto folders; S3 has no folders, so it takes the name as the key.
+// Neither is allowed to invent a layout of its own, because two implementations that disagree
+// about where a segment lives are two backups that cannot be swapped.
+//
+// Async in the `Provider` trait's shape: `impl Future + Send` on a `Sync` trait, so there is no
+// boxing and no `async_trait`.
+
+use std::future::Future;
+
+pub trait BackupStore: Sync {
+    /// Whole, or not at all. Both implementations write a blob in one request, so a name either
+    /// does not exist or names every byte of a segment; a pass cut off halfway leaves the segments
+    /// it finished and nothing else. `pass` depends on that and `tests.rs` holds it to it.
+    fn put(&self, name: &str, bytes: &[u8]) -> impl Future<Output = Result<(), String>> + Send;
+
+    fn get(&self, name: &str) -> impl Future<Output = Result<Vec<u8>, String>> + Send;
+
+    /// Every name under a prefix, in no particular order. The caller sorts what it needs sorted.
+    fn list(&self, prefix: &str) -> impl Future<Output = Result<Vec<String>, String>> + Send;
+}