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

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,