docs(readme): drop an ordering claim scenario 9 does not make

The previous wording said the unshare pass aborts the clone "before the copy's
own exit status is ever consulted", which describes neither version. Unmutated,
the status is consulted immediately after the copy and fires first, so the
unshare pass is never reached; mutated, there is no check left to consult at
either point. As written a reader could take it for a claim that
unshare_mutable_paths runs before the torn-clone condition inside
hardlink_clone_into, which is the kind of ordering this file is otherwise
careful to state exactly (see the reader-marker ordering proof it sits under).

Names the mutation instead: deleting the exit-status check does not change the
outcome, because the unshare pass aborts the clone in its place. The mechanism
is unchanged and still holds — `cp -al` over a mode-000 source creates the
destination preserving mode 000 before failing, and `find | xargs` over that
returns 1 under pipefail, which _unshare_files propagates.

README.md

@@ -414,9 +414,10 @@ Where more than one guard could catch a fault, a scenario should assert
 green because a sibling fires in its place. Scenarios 8a to 8d and 10 of the
 seed suite do, and each is reddened by exactly one mutation of the clone's
 checks. Scenario 9 does not, and a mutation still survives it: with its source
-unreadable, `cp -al` leaves the staging directory at mode `000`, so the
+unreadable, `cp -al` leaves the staging directory at mode `000`, so deleting
-unshare pass aborts the clone before the copy's own exit status is ever
+the exit-status check does not change the outcome — the unshare pass aborts
-consulted, and the assertion is satisfied down a path it was not written for.
+the clone instead, and the assertion is satisfied down a path it was not
+written for.
 
 That is the standing hazard here, and it is not hypothetical. Two guards that
 can each catch the same fault mask each other, so **neither** is individually