Make the server authoritative for what endpoints watch and launch

Fleet health showed dncMain.exe red on endpoints that never ran eDNC. Three
layers each re-added the monitor, so fixing any one of them in isolation left
the others to put it back.

The installer baked a watch list into appsettings.json on every package, and
appsettings.json is never rewritten on the box, so an entry outlived whatever
policy justified it. The server auto-attached shipped monitors by PC type name.
The agent then UNIONED the server's resolved list with its local one, so an
entry could never be removed from the server side at all.

Now: the installer seeds nothing, auto-attach by PC type is gone, and
MonitorConfig.Merge replaces the local list with the server's. Null and empty
stay distinct - null means the fetch failed so keep what we have, empty means
watch nothing. Collapsing those blanks monitoring fleet-wide on one failed HTTP
call, or makes detaching the last monitor silently do nothing forever.

Ingest filters reported services against the resolved monitors as well. The
agent config sits on the endpoint, so it is not a trustworthy account of what
that endpoint should be reporting.

Launch paths move the same way, which exposed an older bug. MTConnect installs
to ProgramData and starts through run.bat, but LaunchPathPolicy approved only
the Program Files roots, so the launchpath on its shipped monitor row - seeded
in 0006, present from the start - was rejected every time as outside every
approved root. That was invisible because a local launchpaths entry wins in
ResolveLaunchPath and never reaches validation; remote start worked only
through the bypass. The same precedence meant editing an eDNC, UDC or MTConnect
path in the WebUI could never reach an existing endpoint.

So ProgramData is approved and the local launch map ships empty. ProgramData is
world-writable and the agent launches as SYSTEM, which is why it was excluded
originally; it is deliberately too broad for now and carries a REVISIT comment.
The remaining gates still hold - admin-configured monitor row, exists,
launchable extension, re-checked after symlink resolution. Narrowing it to
ProgramData\udc needs the fleet's non-Program-Files install locations
confirmed first.

Also seeds the Office ProPlus LTSC monitor templates, x64 and x86 as separate
rows since they differ only by path, and adds an agent test project. It links
the platform-pure sources rather than referencing the net8.0-windows assembly
so the semantics run on the Linux CI runners. Writing those tests caught a
merge bug where only the dedupe key was trimmed and the stored name was not.

Note for the wj merge: plugins/usb/frontend/views/usbSettings.spec.js fails on
this branch and is untouched here. Commit da91a29 added four kiosk settings the
save assertion does not expect. The spec looks like the stale side, but that is
the usb author's call - flagging rather than guessing.

plugins/endpoints/api/siteagent.py

@@ -201,21 +201,39 @@ _BASE_APPSETTINGS = {
     'adoptonfirstrun': True,
     'utilitiespath': '',
     'logpath': '',
+    # Shipped EMPTY, deliberately. The server decides what an endpoint watches:
+    # the agent fetches its watch list from /api/endpoints/monitors/resolved
+    # every telemetry cycle and REPLACES this list with the answer, so anything
+    # seeded here is overwritten within one cadence anyway.
+    #
+    # It used to seed dncMain.exe, udc.exe, agent.exe and the MTConnect service,
+    # which is why every endpoint in the fleet reported eDNC regardless of what
+    # it actually ran. Back when the agent UNIONED the two lists, a baked-in
+    # entry could never be retracted from the server, so detaching a monitor in
+    # the WebUI silently did nothing on deployed endpoints and Fleet health
+    # surfaced dncMain everywhere. Seeding anything here re-creates that class of
+    # bug for as long as the affected packages stay in the field.
+    #
+    # To watch a process or service, attach a monitor to the PC type in the
+    # WebUI. That reaches every endpoint with no rebuild and no redeploy.
     'monitors': {
-        'processes': [
-            {'name': 'dncMain.exe', 'app': 'eDNC'},
-            {'name': 'udc.exe', 'app': 'Universal Data Collector'},
-            {'name': 'agent.exe', 'app': 'MTConnect'},
-        ],
-        'services': [
-            {'name': 'MTConnect UDC Agent', 'app': 'MTConnect'},
-        ],
-    },
-    'launchpaths': {
-        'DncMain.exe': 'C:\\Program Files (x86)\\Dnc\\bin\\DncMain.exe',
-        'UDC.exe': 'C:\\Program Files\\UDC\\UDC.exe',
-        'agent.exe': 'C:\\ProgramData\\udc\\mtconnect_udc\\agent\\run.bat',
+        'processes': [],
+        'services': [],
     },
+    # Intentionally EMPTY, like monitors above, and for the same reason. Launch
+    # paths are server authoritative: they ride on the monitor rows the WebUI
+    # owns and reach the agent through /api/endpoints/monitors/resolved, so
+    # editing a path in the WebUI reaches every endpoint with no rebuild.
+    #
+    # A local entry here WINS over the server path AND bypasses the agent's
+    # LaunchPathPolicy validation (see CommandExecutor.ResolveLaunchPath), which
+    # is exactly how a stale pin outlives the configuration that justified it.
+    # eDNC, UDC and MTConnect all carry their launchpath on the shipped monitor
+    # rows instead.
+    #
+    # Seed an entry here only as a deliberate per-site override, accepting that
+    # the endpoint stops tracking WebUI changes for that image.
+    'launchpaths': {},
     # Approved scheduled task paths for scheduledtask_run. Shipped empty, which
     # means the agent falls back to ScheduledTaskPolicy.DefaultApprovedTaskPaths
     # (the Corporate Tools set). Listing entries here REPLACES those defaults, so