Merge docs/deploy-provenance-rows: 08-11/08-12 wonder deploys recorded; backup dirs read as a provenance chain

Adds the two wonder rows that were deliberately withheld on 2026-08-11
while the pre-55f2889 SHA was unsettled. It is settled: b948e69 (08-09)
and 0a9715d (08-11) were never competing claims about one binary, they
are two deploys two days apart.

What settled it is worth recording as a technique in its own right, so
it goes in as a fourth way to identify a build: each Server.bak.<ts>
holds the exe that deploy REPLACED, so a VersionInfo sweep across the
backups reconstructs a host's deploy history from the host alone — no
repo access, no deploy record. The subtlety that makes it readable is
that a backup's timestamp dates the NEXT deploy, not the build inside
it. Reading a file version is non-destructive, unlike opening a SQLite
store in a backup directory.

Also records the full garbage version stamp recovered from the 08-09
binary, because the failure mode is a false positive rather than a
blank: "0.1.2+fatal:..." reads like a version that succeeded and then
picked up noise, when the leading 0.1.2 is just the static base <Version>
every build carries. For a binary in that window the commit is not
recoverable from the binary at all, so finding nothing is the expected
result rather than evidence against a SHA established another way.

Provenance is stated per cell rather than uniformly: the worker SHAs on
the new rows are carried forward and marked unconfirmed, b948e69 rests
on PDB hash plus the contemporaneous record and never on a stamp, and
55f2889 was read from the live stamp, which is trustworthy only because
it postdates 0152180.

docs/GatewayConfiguration.md

@@ -254,6 +254,7 @@ dev/test GLAuth posture (`glauth.md`), not a production posture.
 | `MxGateway:Ldap:UserNameAttribute` | `cn` | LDAP attribute holding the login user name. |
 | `MxGateway:Ldap:DisplayNameAttribute` | `cn` | LDAP attribute holding the display name. |
 | `MxGateway:Ldap:GroupAttribute` | `memberOf` | LDAP attribute enumerating group membership (mapped to dashboard roles via `MxGateway:Dashboard:GroupToRole`). |
+| `MxGateway:Ldap:FallbackServers` | *(empty)* | Ordered backup LDAP endpoints tried when the primary fails with a system-side error (connect/TLS, service-account bind, or search) — **not** when a user's credentials are simply wrong. Each entry is `host` (adopting `Port`) or `host:port`. Empty leaves single-endpoint behaviour exactly as before. Endpoint preference is sticky: the last endpoint that answered keeps being used until it fails. The `Transport` / `AllowInsecure` policy applies to every endpoint — a fallback is not a way to downgrade TLS. Entries are parsed at startup and a malformed one fails the boot, so a typo'd backup DC cannot lie dormant until the outage it exists to survive. Requires ZB.MOM.WW.Auth 0.2.0+. |
 
 When LDAP is enabled, `Server`, `SearchBase`, `ServiceAccountDn`,
 `ServiceAccountPassword`, and the attribute names must be non-blank, and `Port`

docs/runbooks/IdentifyingADeployedBuild.md

@@ -20,6 +20,20 @@ failure text was stamped as the source revision. The observed form is:
 0.1.2+fatal: cannot change to ...
 ```
 
+The full string recovered from wonder's 2026-08-09 server binary (read 2026-08-12) shows the whole
+failure, including the mismatched `'` … `"` that caused it:
+
+```
+0.1.2+fatal: cannot change to 'C:\build\mxgw-deploy\src" rev-parse --short HEAD': Invalid argument
+```
+
+**Do not read the leading `0.1.2` as provenance.** It is the static base `<Version>` every build
+carries, not a truncated SHA. The hazard is a false positive rather than a blank: `0.1.2+fatal:…`
+reads like a version that succeeded and then picked up noise, when in fact there is no usable
+identity anywhere in the string. For a binary built in this window the commit is **not recoverable
+from the binary at all** — so finding nothing is the expected result, not evidence against a SHA
+established another way.
+
 `0152180` (2026-08-10 05:49, merged in `c46e5bb`) fixed it two ways: the quoted path gained a
 trailing `.` so the separator can no longer escape the quote, and `SourceRevisionId` is now gated on
 a short-SHA shape so no future git failure text can become the revision either.
@@ -61,6 +75,15 @@ In rough order of cost:
    `Worker.bak-20260809-planwrites`). Those conventions place a build in time and intent, and an
    accidental or off-book deploy tends not to follow them.
 
+4. **The host's own backup directories, read as a chain.** Each `Server.bak.<timestamp>` holds the
+   exe that deploy *replaced*, so a sweep of `VersionInfo` across them reconstructs the host's deploy
+   history from the host itself, with no repo access and no deploy record. A backup stamped
+   `20260811T060739` containing an exe written 2026-08-09 is the 08-09 build being displaced — the
+   backup's timestamp dates the *next* deploy, not the build inside it. Reading a file's version is
+   non-destructive, unlike opening a SQLite store in a backup directory, which mutates it. This is
+   what established that wonder's `b948e69` and `0a9715d` were two deploys two days apart rather
+   than two competing claims about one binary.
+
 Note that **mixed Server and Worker SHAs are deliberate**, not drift: the two are swapped
 independently whenever the contracts are wire-identical, so a host legitimately runs one commit for
 the server and a later one for the worker.
@@ -71,6 +94,18 @@ the server and a later one for the worker.
 |---|---|---|---|
 | 2026-08-09 | windev (`10.100.0.48`) | `b948e69` (`Server-20260809`) | `53f69cd` |
 | 2026-08-09 | `wonder-app-vd03` | `b948e69` | `53f69cd` |
+| 2026-08-11 | `wonder-app-vd03` | `0a9715d` (this deploy wrote `Server.bak.20260811T060739`, holding the displaced 08-09 build) | *carried forward* |
+| 2026-08-12 | `wonder-app-vd03` | `55f2889` (this deploy wrote `Server.bak.20260812T040122`, holding `0a9715d`) | *carried forward* |
+
+The two wonder rows after 08-09 are **server swaps**; their worker cells are carried forward from the
+08-09 entry rather than re-verified, so treat the worker SHA there as unconfirmed. Their server SHAs
+come from the backup-chain read described above (technique 4), except `55f2889`, which was read
+directly from the live exe's stamp — trustworthy because it postdates `0152180`.
+
+`b948e69` is **confirmed by PDB source-hash match plus the contemporaneous record, never by a version
+stamp** — that build falls in the broken-stamp window and its stamp is structurally unavailable (see
+the first section). `0a9715d` is the first wonder build to stamp cleanly, since `0152180` landed
+before it.
 
 The 2026-08-09 deploy was **two separate swaps**, which is why a single build time does not describe
 it: the 2026-08-11 investigation dated the server file write to 19:20:24 and the worker to 19:50:06,

src/ZB.MOM.WW.MxGateway.IntegrationTests/ZB.MOM.WW.MxGateway.IntegrationTests.csproj

@@ -22,8 +22,8 @@
     (IntegrationTests-028).
   -->
   <ItemGroup>
-    <PackageReference Include="ZB.MOM.WW.Auth.Abstractions" Version="0.1.5" />
+    <PackageReference Include="ZB.MOM.WW.Auth.Abstractions" Version="0.2.0" />
-    <PackageReference Include="ZB.MOM.WW.Auth.Ldap" Version="0.1.5" />
+    <PackageReference Include="ZB.MOM.WW.Auth.Ldap" Version="0.2.0" />
     <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="10.0.7" />
     <PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="10.0.7" />
   </ItemGroup>

src/ZB.MOM.WW.MxGateway.Server/Configuration/EffectiveLdapConfiguration.cs

@@ -11,4 +11,5 @@ public sealed record EffectiveLdapConfiguration(
     string ServiceAccountPassword,
     string UserNameAttribute,
     string DisplayNameAttribute,
-    string GroupAttribute);
+    string GroupAttribute,
+    IReadOnlyList<string> FallbackServers);

src/ZB.MOM.WW.MxGateway.Server/Configuration/GatewayConfigurationProvider.cs

@@ -30,7 +30,8 @@ public sealed class GatewayConfigurationProvider(IOptions<GatewayOptions> option
                 ServiceAccountPassword: RedactedValue,
                 UserNameAttribute: value.Ldap.UserNameAttribute,
                 DisplayNameAttribute: value.Ldap.DisplayNameAttribute,
-                GroupAttribute: value.Ldap.GroupAttribute),
+                GroupAttribute: value.Ldap.GroupAttribute,
+                FallbackServers: value.Ldap.FallbackServers),
             Worker: new EffectiveWorkerConfiguration(
                 ExecutablePath: value.Worker.ExecutablePath,
                 WorkingDirectory: value.Worker.WorkingDirectory,

src/ZB.MOM.WW.MxGateway.Server/Configuration/LdapOptions.cs

@@ -68,4 +68,19 @@ public sealed class LdapOptions
 
     /// <summary>Gets the LDAP attribute name for group membership.</summary>
     public string GroupAttribute { get; init; } = "memberOf";
+
+    /// <summary>
+    /// Gets the ordered fallback LDAP endpoints (<c>"host"</c> or <c>"host:port"</c>) the shared
+    /// provider walks when the primary fails with a system-side error. Empty (the default) leaves
+    /// single-endpoint behaviour unchanged. Mirrors
+    /// <see cref="ZB.MOM.WW.Auth.Abstractions.Ldap.LdapOptions.FallbackServers"/>, added in
+    /// ZB.MOM.WW.Auth 0.2.0.
+    /// <para>
+    /// Carried here only so the effective-config display does not hide a configured backup DC —
+    /// nothing on the gateway side reads it. Entry syntax is validated at boot by the shared
+    /// <c>LdapOptionsValidator</c>, which owns the (internal) parser; re-validating here would
+    /// mean a second, drifting copy of that grammar.
+    /// </para>
+    /// </summary>
+    public IReadOnlyList<string> FallbackServers { get; init; } = [];
 }

src/ZB.MOM.WW.MxGateway.Server/Dashboard/Components/Pages/SettingsPage.razor

@@ -26,6 +26,21 @@ else
                     <tr><th scope="row">Run migrations</th><td>@Snapshot.Configuration.Authentication.RunMigrationsOnStartup</td></tr>
                     <tr><th scope="row">LDAP enabled</th><td>@Snapshot.Configuration.Ldap.Enabled</td></tr>
                     <tr><th scope="row">LDAP server</th><td>@Snapshot.Configuration.Ldap.Server:@Snapshot.Configuration.Ldap.Port</td></tr>
+                    <tr>
+                        <th scope="row">LDAP fallback servers</th>
+                        @* Rendered even when empty: "none" is the operationally interesting answer
+                           on a host someone believes has a backup DC configured. *@
+                        <td>
+                            @if (Snapshot.Configuration.Ldap.FallbackServers.Count == 0)
+                            {
+                                <span class="text-muted">none</span>
+                            }
+                            else
+                            {
+                                <code>@string.Join(", ", Snapshot.Configuration.Ldap.FallbackServers)</code>
+                            }
+                        </td>
+                    </tr>
                     <tr><th scope="row">LDAP transport</th><td>@Snapshot.Configuration.Ldap.Transport</td></tr>
                     <tr><th scope="row">LDAP search base</th><td><code>@Snapshot.Configuration.Ldap.SearchBase</code></td></tr>
                     <tr><th scope="row">LDAP service account</th><td><code>@Snapshot.Configuration.Ldap.ServiceAccountDn</code></td></tr>

src/ZB.MOM.WW.MxGateway.Server/ZB.MOM.WW.MxGateway.Server.csproj

@@ -10,20 +10,20 @@
 
   <ItemGroup>
     <PackageReference Include="Grpc.AspNetCore" Version="2.76.0" />
-    <PackageReference Include="ZB.MOM.WW.Auth.Abstractions" Version="0.1.5" />
+    <PackageReference Include="ZB.MOM.WW.Auth.Abstractions" Version="0.2.0" />
-    <PackageReference Include="ZB.MOM.WW.Auth.Ldap" Version="0.1.5" />
+    <PackageReference Include="ZB.MOM.WW.Auth.Ldap" Version="0.2.0" />
-    <PackageReference Include="ZB.MOM.WW.Auth.ApiKeys" Version="0.1.5" />
+    <PackageReference Include="ZB.MOM.WW.Auth.ApiKeys" Version="0.2.0" />
-    <PackageReference Include="ZB.MOM.WW.Auth.AspNetCore" Version="0.1.5" />
+    <PackageReference Include="ZB.MOM.WW.Auth.AspNetCore" Version="0.2.0" />
     <PackageReference Include="ZB.MOM.WW.Audit" Version="0.1.0" />
     <PackageReference Include="ZB.MOM.WW.Theme" Version="0.4.1" />
     <PackageReference Include="ZB.MOM.WW.Configuration" Version="0.1.0" />
-    <PackageReference Include="ZB.MOM.WW.Health" Version="0.2.0" />
+    <PackageReference Include="ZB.MOM.WW.Health" Version="0.3.0" />
     <PackageReference Include="ZB.MOM.WW.Telemetry" Version="0.1.0" />
     <PackageReference Include="ZB.MOM.WW.Telemetry.Serilog" Version="0.1.0" />
     <PackageReference Include="ZB.MOM.WW.GalaxyRepository" Version="0.2.0" />
-    <PackageReference Include="ZB.MOM.WW.Secrets" Version="0.6.1" />
+    <PackageReference Include="ZB.MOM.WW.Secrets" Version="0.6.2" />
-    <PackageReference Include="ZB.MOM.WW.Secrets.Abstractions" Version="0.6.1" />
+    <PackageReference Include="ZB.MOM.WW.Secrets.Abstractions" Version="0.6.2" />
-    <PackageReference Include="ZB.MOM.WW.Secrets.Ui" Version="0.6.1" />
+    <PackageReference Include="ZB.MOM.WW.Secrets.Ui" Version="0.6.2" />
     <PackageReference Include="Serilog.AspNetCore" Version="10.0.0" />
     <PackageReference Include="Serilog.Sinks.Console" Version="6.1.1" />
     <PackageReference Include="Serilog.Sinks.File" Version="7.0.0" />