chore: staging publishes with a viewer that has publication mode

assets/config/staging.json

@@ -1,5 +1,5 @@
 {
-  "configVersion": 4,
+  "configVersion": 5,
   "defaultArweaveGatewayUrl": "https://turbo-gateway.com",
   "defaultArweaveGatewayForDataRequest": {
     "label": "Turbo Gateway",
@@ -12,7 +12,7 @@
   "allowedDataItemSizeForTurbo": 100000,
   "stripePublishableKey": "pk_live_51JUAtwC8apPOWkDLMQqNF9sPpfneNSPnwX8YZ8y1FNDl6v94hZIwzgFSYl27bWE4Oos8CLquunUswKrKcaDhDO6m002Yj9AeKj",
   "enableSyncFromDriveState": true,
-  "publicationViewer": "ardrive",
+  "publicationViewer": "zW-6ZxX-hWnMndFC4twsBpFuHADb6jUQpmh1lb2sU_M",
   "publicationGatewayUrl": "https://ardrive.net",
   "enableDriveStatePublishing": true,
   "uploadThumbnails": true,

docs/PUBLICATIONS.md

@@ -224,13 +224,18 @@ serving it and the gateway it detected, nothing else.
   manifest ID (`x-arns-resolved-id`) with a plain HTTP read through
   ardrive.net. That needs no wallet, so it works before names do in the app (see
   [Names](#names)).
-- Production sets `ardrive`, the name the production deploy moves. Staging has
-  no name and pushes to `dev` never upload to Arweave, so the staging and
-  development configs also use `ardrive`: a page published from staging pins
-  the current production release. To try a viewer built from a branch, run
-  *Staging build to Arweave* (`staging-arweave.yaml`) and put the manifest ID
-  from its job summary in the stored config (`flutter.config` in local
-  storage). The phase 1 test-page tool takes a manifest ID directly.
+- Production sets `ardrive`, the name the production deploy moves, and the
+  development config uses it too.
+- Staging has no name, and pushes to `dev` never upload to Arweave. So
+  `staging.json` pins a fixed manifest ID: a build of `dev` uploaded by
+  *Staging build to Arweave* (`staging-arweave.yaml`). Pages published from
+  staging open with that viewer. To move staging to a newer build, run the
+  workflow again and put the new ID in `staging.json` with a `configVersion`
+  bump.
+- To try a viewer built from a branch, run the same workflow on that branch
+  and put the manifest ID from its job summary in your stored config
+  (`flutter.config` in local storage). The phase 1 test-page tool takes a
+  manifest ID directly.
 - CI warms the bundle after each deploy by reading every file once through
   turbo-gateway.com and ardrive.net.
 

lib/services/config/app_config.dart

@@ -53,9 +53,11 @@ class AppConfig {
 
   /// The ArDrive release a new publication runs (docs/PUBLICATIONS.md, "The
   /// viewer bundle"): a release manifest's transaction ID as it is, or an
-  /// ArNS name, read through the gateway for the release it points at. Every
-  /// flavour uses `ardrive`, the production release, so a publication made
-  /// anywhere opens the way it will for everyone.
+  /// ArNS name, read through the gateway for the release it points at.
+  /// Production and development use `ardrive`, the production release.
+  /// Staging pins a fixed manifest ID of a dev build uploaded by *Staging
+  /// build to Arweave*, so pages published from staging open with the viewer
+  /// being tested.
   final String publicationViewer;
 
   /// The one gateway every publication is on, whatever the data gateway