docs(runbook): state what the identification evidence actually rests on

Two precision fixes to the runbook landed in fd0e88e, both making it weaker in
the sense that matters.

The PDB source-hash entry read as though hashes settled the 2026-08-09
provenance question by themselves. They did not: a hash match and a
contemporaneous deploy record written that evening independently named the same
two commits, and the agreement is what makes the result trustworthy. A hash
match alone tells you which sources a binary was built from — not that the build
was intentional, nor which host it reached. A future reader holding only one of
the two derivations should know to look for a second.

The two-swap timeline was asserted from the investigation's timestamps, which a
later reader cannot re-derive. It is also confirmable from artifacts still on
disk — windev keeps two worker backup directories from that day and wonder one,
because there were two worker operations. Records that, so the story can be
checked against the boxes rather than believed.

docs/runbooks/IdentifyingADeployedBuild.md

@@ -48,7 +48,13 @@ In rough order of cost:
    `statuses` proves it is not. Keep it non-destructive by writing to a read-only tag — the refusal
    still exercises the path and returns `OPERATIONAL_ERROR` with detail `1007`.
 2. **PDB source hashes.** Slower, needs the deployed symbols, but independent of anything the build
-   stamped. This is what settled the 2026-08-11 investigation.
+   stamped. **Do not read this as *the* technique on its own.** What settled the 2026-08-11
+   investigation was two independent derivations agreeing: a PDB source-hash match, and a
+   contemporaneous deploy record written the same evening that named the same two commits. The
+   convergence is the result's strength, not either method alone — a hash match tells you which
+   sources a binary was built from, but not that the build was intentional or which host it went to.
+   A reader with only one of the two available should weight it accordingly and look for a second
+   line of evidence.
 3. **Deployment-side naming.** Since 2026-08-07 the server deploys to a dated directory
    (`Server-YYYYMMDD`) with the NSSM `Application`/`AppDirectory` repointed at it, and backup
    directories carry operator-chosen labels naming the work (for example
@@ -68,8 +74,14 @@ the server and a later one for the worker.
 
 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,
-the latter two minutes after `53f69cd` merged at 19:48. The two worker backup directories from that
-day are the second swap's fingerprint, not redundancy.
+the latter two minutes after `53f69cd` merged at 19:48, with a matching service stop/start at
+19:50:29/34.
+
+That reading is confirmable from artifacts still on disk, without trusting the narrative: windev
+carries **two** worker backup directories from that day (`Worker.bak-20260809` and
+`Worker.bak-20260809-planwrites`), and wonder carries `Worker.bak.20260809-planwrites`. Two backups
+because there were two worker operations. This is easy to misread as redundancy — it is the second
+swap's fingerprint.
 
 ## The 2026-08-09 deploy returned the worker to mainline