Document runtime-confirmed CI signer selection and crypto reuse

docs/ci-validate-file-object.md

@@ -1,8 +1,9 @@
 # CiValidateFileObject: validation flag 0x00000020
 
-Issue #3 is **documented; kernel runtime verification is pending**. The probe
-builds and its plumbing is covered by host tests, but those tests do not execute
-Windows Code Integrity. Do not close the runtime-testing portion on that basis.
+Issue #3 is **documented; its TESTSIGNING-off runtime experiment is pending**.
+A related signer-selection experiment has now run successfully on Windows 11
+22631 with TESTSIGNING enabled (below). That run does not close the requested
+19041/19045 flag 0 versus 0x20 TESTSIGNING-off comparison.
 
 ## Meaning supported by the evidence
 
@@ -181,6 +182,41 @@ Self-signed acceptance must be reported explicitly, not confused with public-CA
 publisher trust. Do not use this flag as a new production default based only on
 one positive fixture.
 
+## Multiple signatures: a separate kernel experiment
+
+`0x20` is an accepted-root control, not a recovered "PE image" type flag.
+In the examined 22621.2792 and modern 26100 x64 bodies it leaves the
+preferred-signing-level search active. `PolicyInfo` can therefore describe a
+nested Microsoft signature even when the primary company signature also verifies.
+
+The first-success guard tests aggregate masks `0xE47FFF87` (22621.2792) and
+`0xE41FFF87` (modern 26100). `0x20` intersects neither; `0x80` intersects both.
+Compare flags `0x20` versus `0xA0`, requested signing level zero, on the same
+stable dual-signed file. Record the actual selected leaf/thumbprint, both policy
+statuses and signing time. Do not interpret status success alone as selection
+of the company certificate. First successful does not necessarily mean first
+listed: CI may reject the primary and continue.
+
+`0x80` has additional policy and fallback effects. It has not been published as
+a supported Domito constant or a production default. The companion research
+`SIGNATURE-SELECTION.md` provides the full static evidence and an alternative
+primary-signature path using `CiCheckSignedFile`.
+
+A user-run kernel probe on Windows 11 **10.0.22631 x64**, CI options **0x00080207**
+(TESTSIGNING enabled), confirms the selection difference for the exact dual-signed
+BthPS3 fixture: `0x20` returns Microsoft, while `0xA0` returns the Nefarius leaf
+`FF0CCF318FD8C14775023A0B52C28FFCCA59D7F7` and signing time
+**2026-10-02T18:32:01.000Z**. Direct primary SHA-256 `CiCheckSignedFile` returns
+the same Nefarius leaf, signer/timestamp policies and signing time. All three
+calls return STATUS_SUCCESS; all policy VerificationStatus fields also succeed.
+The file digest is identical across calls, before/after file hashes match, and
+TraceFmt reports 149 events with no losses, format errors or unknown formats.
+
+The companion `signature-selection/runtime-22631-bthps3.json` records exact
+trace hashes and the on-disk CI hash. This is one test-signing-enabled run;
+TESTSIGNING-off, other builds/policies and general signature enumeration remain
+unverified. `0xA0` does not mean "select any desired publisher".
+
 ## Checks available without the VM
 
 From an x64 Visual Studio developer shell: