fix: fail the install when a fleet enrollment cannot add its include

ScheduleEnrollFleet only logged a NOTE when the installer was not allowed to
change the configuration, and then enrolled anyway. The result is a host that
generates a key pair, spends its one-time bootstrap token, registers with the
fleet server and syncs - while nothing ever reads the configuration that comes
back, because ScheduleWriteConfig never added the include that points at it.
Managed on paper, unmanaged in practice, and the note lands in an MSI log that
nobody reads on an unattended install.

Fail instead, before the token is spent. The test is the same one
ScheduleWriteConfig applies (CONF_CAN_CHANGE = 1), so the install fails exactly
when the include would not have been written, and the error carries
CONF_CAN_CHANGE_REASON so the log says which of the several reasons applied.

Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Michael Medin <michael@medin.name>

Author: mickem

docs/docs/setup/installing.md

@@ -341,6 +341,10 @@ A few things worth knowing:
 - **Enrollment is required to succeed.** If the fleet server cannot be reached, or rejects the token, the install fails
   with an error explaining what went wrong rather than leaving you with an agent that never joined the fleet. Bootstrap
   tokens are one-time and are burned on first use, so a rejected token means generating a new install command.
+- **The installer has to be allowed to write the configuration.** Enrollment is what adds the include that makes the
+  host read what the fleet server sends it, so combining `FLEET_SERVER` with `ALLOW_CONFIGURATION=0` - or installing
+  onto a configuration the installer cannot update - fails the install rather than enrolling a host that then ignores
+  everything the fleet server tells it. The install log names the reason the configuration was held to be unchangeable.
 - **An already enrolled host keeps its identity.** If `agent-state.json` already exists (an upgrade, a repair, or a
   re-install over an existing installation) the enrollment is skipped and the existing identity is kept. Delete the file
   to enroll again.

installer_lib/installer_lib.cpp

@@ -1158,13 +1158,23 @@ extern "C" UINT __stdcall ScheduleEnrollFleet(MSIHANDLE hInstall) {
     }
 
     // The include of the fleet-managed configuration is written by
-    // ScheduleWriteConfig, which only writes anything when the installer is
-    // allowed to change the configuration. Say so rather than leaving the
-    // operator with an enrolled host whose fleet configuration is never read.
+    // ScheduleWriteConfig, and only when it is allowed to change the
+    // configuration - the exact test repeated here, so we fail precisely when
+    // the include would not be written. Without it the host enrolls, reports
+    // in and syncs, but nothing ever reads what the fleet server sends back:
+    // managed on paper, unmanaged in practice. The enrollment that follows
+    // burns the bootstrap token, so this has to fail before the token is
+    // spent, not leave a note in a log nobody reads on an unattended install.
     if (h.getMsiPropery(INT_CONF_CAN_CHANGE) != L"1") {
-      h.logMessage(
-          L"NOTE: configuration changes are not allowed, so the fleet configuration include cannot be added. Add it manually: [/includes] "
-          L"fleet=${shared-path}/fleet/fleet.ini");
+      std::wstring reason = boost::algorithm::trim_copy(h.getMsiPropery(INT_CONF_CAN_CHANGE_REASON));
+      if (reason.empty()) reason = L"the installer is not allowed to change the configuration";
+      h.errorMessage(
+          L"Refusing to enroll with a fleet server: the configuration cannot be changed (" + reason +
+          L"), so the include of the fleet-managed configuration ([/includes] fleet=${shared-path}/fleet/fleet.ini) cannot be added and this host "
+          L"would never read the configuration the fleet server sends it. Let the installer write the configuration (do not pass "
+          L"ALLOW_CONFIGURATION=0, or pass CONF_CAN_CHANGE=1), or install without FLEET_SERVER/FLEET_TOKEN and enroll afterwards with `nscp enroll` "
+          L"once the include is in place.");
+      return ERROR_INSTALL_FAILURE;
     }
 
     msi_helper::custom_action_data_w data;