docs(crash-reporting): say 'undetectable', not 'survives', about the guard mutation

In mutation-testing terms a mutant that *survives* is one the tests fail to catch,
so 'neither survives mutation alone' asserted the opposite of the measured result.

src/shared/windows-launch-failure-code.test.ts

@@ -53,7 +53,7 @@ describe('decodeWindowsLaunchFailureCode', () => {
   // Mutation-tested, and the result is worth stating exactly: adding `>>> 0` alone changes
   // nothing (the guard rejects these first) and removing the guard alone changes nothing (the
   // object lookup misses on a negative or fractional key). Each is individually a no-op, so no
-  // test can catch either on its own. Together they are not, and that is the realistic
+  // test can catch either on its own. Together they are not a no-op, and that is the realistic
   // regression — whoever adds the coercion sees the guard as redundant and drops it. The last
   // two rows catch exactly that, because ToUint32 maps them onto real keys: 1.5 -> 1
   // (SBOX_ERROR_GENERIC) and -4294967278 -> 18 (CREATE_PROCESS).

src/shared/windows-launch-failure-code.ts

@@ -169,9 +169,9 @@ export function decodeWindowsLaunchFailureCode(
   // `1.5 >>> 0` is 1 (SBOX_ERROR_GENERIC) and `-4294967278 >>> 0` is 18 (CREATE_PROCESS).
   //
   // This guard and that missing coercion are each individually a no-op — the object lookup
-  // already misses on a negative or fractional key — so neither survives mutation alone.
-  // Removing BOTH is the regression, and it is the likely one: adding the coercion makes this
-  // guard look dead. Do not "prove" it dead and remove it; the test file pins the pair.
+  // already misses on a negative or fractional key — so changing either one alone is
+  // undetectable. Removing BOTH is the regression, and it is the likely one: adding the
+  // coercion makes this guard look dead. Do not "prove" it dead; the test file pins the pair.
   if (!Number.isInteger(exitCode) || exitCode < 0) {
     return null
   }