fix(#3309): applyRepairs must not count a failed repair as applied

applyRepairs pushed a diagnostic's code onto applied unconditionally
after the try/catch around runRepairAction, even when the handler
threw (caught, recorded in details with success:false) or otherwise
failed — making applied mean "attempted" rather than "succeeded," with
no test exercising the failure path. Found by the Spec-axis orthogonal
review.

applied now only receives a code when the repair actually succeeded;
a failed attempt is still fully recorded in details (success:false,
the error message) but no longer misreported as applied. Adds a
regression test forcing addNyquistKey to throw (ENOENT on a config.json
that doesn't exist) and asserts it lands in details, not applied.

src/health-diagnostic.cts

@@ -443,6 +443,12 @@ function applyRepairs(
         ...(outcome.detail ? { detail: outcome.detail } : {}),
         ...(outcome.error ? { error: outcome.error } : {}),
       });
+      // `applied` means "the repair actually succeeded", not "was attempted"
+      // — a handler that returns `{success: false}` (or throws, caught
+      // below) is recorded in `details` with its failure, but must not be
+      // reported as applied. `refused` is reserved for the DESTRUCTIVE-risk
+      // gate above; a failed attempt is neither applied nor refused.
+      if (outcome.success) applied.push(code);
     } catch (err) {
       details.push({
         code,
@@ -451,7 +457,6 @@ function applyRepairs(
         error: err instanceof Error ? err.message : String(err),
       });
     }
-    applied.push(code);
   }
 
   return { applied, refused, details };