fleetd #618: fix the third stale spot the brief missed

The method-level javadoc on FleetConfig.warnConflictingAutoCompactWindows
(above the log.warn call) still claimed the autoCompactWindow vs
CLAUDE_CODE_AUTO_COMPACT_WINDOW precedence was 'intentionally not
asserted' and cited fleetd.yaml's now-corrected comment as evidence the
question was open. Replace it with the measured answer from #618: the
env var wins, so autoCompactWindow is inert on a profile that sets both.
Kept the WARN-not-throw rationale paragraph above it untouched (#601)
and kept the ClaudeCodeArguments cross-reference, which now points to an
agreeing claim instead of a contradicting one. No behaviour change.

fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java

@@ -2240,11 +2240,11 @@ public record FleetConfig(
      * information — which profiles, and now both values, so they can fix it without reading the
      * source — without ever taking the fleet down.
      *
-     * <p>Which of the two inputs Claude Code actually follows when they disagree is intentionally
-     * <em>not</em> asserted here. {@code ClaudeCodeArguments}'s javadoc used to state the
-     * environment variable always wins; nobody had measured that, and this host's own
-     * {@code fleetd.yaml} asserts the opposite in a comment. This method only detects and reports
-     * the disagreement — see {@link dev.ltms.fleet.launch.ClaudeCodeArguments}.
+     * <p>fleetd #618 measured which of the two inputs Claude Code actually follows when they
+     * disagree: the environment variable wins, so {@code autoCompactWindow} is inert on a profile
+     * that also sets the env var. This method only detects and reports the disagreement — it does
+     * not correct it — see {@link dev.ltms.fleet.launch.ClaudeCodeArguments} for the full measured
+     * precedence.
      *
      * <p>Equal values never warn: either input then produces the same session window, so there is
      * nothing to reconcile.
@@ -2285,9 +2285,11 @@ public record FleetConfig(
         names.sort(String::compareTo);
         detail.sort(String::compareTo);
         log.warn("Claude Code profile(s) {} set disagreeing autoCompactWindow and env."
-                        + "CLAUDE_CODE_AUTO_COMPACT_WINDOW — the daemon starts anyway. Fix by "
-                        + "removing one key or setting equal values on each: {}. Which input Claude "
-                        + "Code actually follows when they disagree is not verified here.",
+                        + "CLAUDE_CODE_AUTO_COMPACT_WINDOW — the daemon starts anyway: {}. fleetd "
+                        + "#618 measured that CLAUDE_CODE_AUTO_COMPACT_WINDOW wins, so "
+                        + "autoCompactWindow is inert on these profiles. Set equal values on each "
+                        + "to resolve this — do not just delete the env var, since that LOWERS the "
+                        + "live window to autoCompactWindow's value rather than fixing anything.",
                 names, String.join(", ", detail));
     }
 

fleetd/src/main/java/dev/ltms/fleet/launch/ClaudeCodeArguments.java

@@ -15,13 +15,15 @@ public final class ClaudeCodeArguments {
      * Append the configured Claude Code auto-compaction window when the profile opts in.
      *
      * <p>This flag and the environment variable {@code CLAUDE_CODE_AUTO_COMPACT_WINDOW} can
-     * disagree. Which one Claude Code actually follows when they do is NOT verified here — this
-     * javadoc used to claim the environment variable always wins, but nobody had measured that, and
-     * this host's own {@code fleetd.yaml} asserts the opposite in a comment. So this javadoc no
-     * longer picks a side. {@link FleetConfig#load(java.nio.file.Path)} only WARNS when a Claude
-     * Code profile sets both to different values (see {@code
+     * disagree, and fleetd #618 measured which one Claude Code actually follows: the environment
+     * variable wins, ahead of this {@code --autocompact} flag, ahead of the settings file, ahead of
+     * clientdata, the experiment, and the model default. So when a profile sets both, the flag this
+     * method appends has NO effect — Claude Code reads {@code CLAUDE_CODE_AUTO_COMPACT_WINDOW}
+     * first and never consults the flag. {@link FleetConfig#load(java.nio.file.Path)} only WARNS
+     * when a Claude Code profile sets both to different values (see {@code
      * FleetConfig.warnConflictingAutoCompactWindows}) — it does not stop the daemon from starting,
-     * and a launched session may end up honouring either window.
+     * and the launched session honours the env var, not this flag. Measured against Claude Code
+     * 2.1.278 (fleetd #618) — a later version could reorder this precedence.
      */
     public static List<String> withAutoCompactWindow(List<String> argv, FleetConfig.Profile profile) {
         if (profile.autoCompactWindow() == null) {