fleetd #393: correct a comment that claimed two tests pin a call they cannot

The comment above the charter writer said flipping that call back to
putArray was "proven load-bearing" and pointed at two named tests. I
mutated exactly that, on the merge commit, and it SURVIVED at 1618 green -
so neither named test covers it, and neither can.

The reason is structural, not a missing test: that writer runs first
against an empty array, so putArray has nothing to replace and the two
idioms are equivalent there. No test can distinguish them. The worker
measured the same thing independently and said so in their report; the
comment was left over from the pre-fix state, where the mutation being
described was a DIFFERENT one (a later writer destroying the charter).

A comment that names tests which do not cover the line is worse than no
comment. The next person mutates the line, sees green, and concludes the
tests are broken.

The corrected version states what each cell actually measures: this line
is unpinnable and why, the later writers ARE pinned and by which test
names, and deleting this line entirely fails the charter-reaches-the-member
assertion - the hole that predates #393.

fleetd/src/main/java/dev/ltms/fleet/member/OpenCodeLauncher.java

@@ -525,17 +525,28 @@ public final class OpenCodeLauncher extends HerdrPeerLauncher {
                 charter.toFile().deleteOnExit();
 
                 // fleetd #393 follow-up: withArray, not putArray. putArray REPLACES whatever node
-                // is already at "instructions" — harmless only as long as this block runs first
-                // against a still-empty root, which is an ordering constraint nothing declared or
-                // tested. The skills writer just below, and the IDE-rules writer further down,
-                // both already use withArray (get-or-create) for exactly this reason; this was the
-                // one straggler. Proven load-bearing on the fleetd #393 merge: flipping this one
-                // call back to putArray left the whole suite green while silently deleting the
-                // charter entry whenever skills or IDE rules ran after it — an opencode member
-                // would launch with no role contract at all, worse than the bug #393 fixed, and
-                // nothing caught it. See OpenCodeLauncherTest's
-                // instructionsArrayHoldsCharterThenIdeRulesInOrder and
-                // instructionsArrayHoldsCharterThenSkillsThenIdeRulesInOrder.
+                // is already at "instructions"; withArray gets-or-creates. All three writers on
+                // this array now use withArray so that write order stops being load-bearing for
+                // whoever adds a fourth.
+                //
+                // Be precise about what this particular line is worth, because an earlier version
+                // of this comment was wrong and claimed too much. THIS call is the one place where
+                // the two idioms are equivalent, and no test can tell them apart: it runs first,
+                // against a still-empty root, so there is never an existing node for putArray to
+                // replace. Measured on the #393 merge: flipping this one call back to putArray
+                // leaves the whole suite green (1618 tests), and always will. The edit is a
+                // readability and future-proofing change with no test behind it, and that is not a
+                // gap anyone can close.
+                //
+                // The ordering hazard is real, just not here. It is the LATER writers that can
+                // destroy earlier entries. Measured on the same merge: flipping the skills writer
+                // below to putArray deletes this charter entry and fails
+                // OpenCodeLauncherTest.instructionsArrayHoldsCharterThenSkillsThenIdeRulesInOrder;
+                // flipping the IDE-rules writer fails that test and
+                // instructionsArrayHoldsCharterThenIdeRulesInOrder. Deleting this line altogether
+                // fails instructionsArrayHoldsExactlyTheCharterWhenNothingElseWritesToIt — the
+                // assertion that a role contract reaches an opencode member at all, which is the
+                // hole that predates #393 and is what actually let the mutation hide.
                 root.withArray("instructions").add(charter.toAbsolutePath().toString());
             }