Fix endpoint user-context collection running in the wrong session

Mapped drives reported Unavailable on endpoints where the operator could
see them fine. The data path was intact; the collection was running under
the wrong token. Mapped drives are per logon token, so an elevated probe
enumerates a different drive table than the interactive user.

Collection:
- Pin the user-context spool path so the probe and service agree on one
  location, and persist/overwrite it instead of deleting on read.
- Refuse to collect while elevated (exit code 2) rather than emitting a
  confident wrong answer, and stamp elevated/username on the spool.
- Reject spools stamped elevated or from an unexpected account on read,
  so an admin run cannot masquerade as valid.
- Log netuse/smbmapping/userlistener counts so each run leaves evidence
  of what it actually saw.

Install and launch context:
- Move collection to a 'ShopDB user-context probe' scheduled task under
  S-1-5-32-545 at RunLevel Limited, the only mechanism that reliably runs
  in the operator's own session. Verify registration and record it in the
  install ledger.
- Stop starting the tray as a child of the elevated installer; explorer.exe
  de-elevates without changing ACCOUNT, so an admin install produced an
  admin tray. The Run key only fires at logon, which left the tray dead on
  a machine already signed in, so add a transient 'ShopDB tray first launch'
  task that starts it once in the existing session and unregisters itself.
- Hide the console window during --collect-usercontext. The agent is a
  console exe; the tray used to mask this with CreateNoWindow, but the
  scheduled task invokes it directly and flashed a window every cycle.

Installer edits are in _install_script() in plugins/endpoints/api/siteagent.py,
which generates the install.ps1 that actually ships. The standalone
agent/installer/install-shopdbagent.ps1 was never shipped once the package
moved to the UI builder and is deleted here to stop the divergence that
caused an earlier fix to land in a file no endpoint ever ran.

Versions: agent 1.10.1, tray 1.3.0. These share the pinned spool path and
must be deployed together.

Pre-existing test failures unrelated to this work (8, identical on a clean
tree): docs publishable/versions, plugin contract symlink scan, import
guard tamper check, security headers upload sandbox, and three endpoint
timestamp tests.

scripts/uninstall-shopdbagent.ps1

@@ -1,10 +1,11 @@
 # uninstall-shopdbagent.ps1
 # ShopDB Endpoint Agent uninstaller. Run from an ELEVATED (admin) PowerShell on
-# the endpoint. Reverses everything install-shopdbagent.ps1 and the site agent
-# generator's install.ps1 create:
+# the endpoint. Reverses everything the site agent generator's install.ps1
+# creates:
 #   - stops and deletes the Windows service
 #   - kills any running agent/tray processes
 #   - removes the tray logon Run key (64-bit and 32-bit views)
+#   - unregisters the ShopDB user-context probe scheduled task
 #   - removes the credential hive HKLM\SOFTWARE\GE\ShopDB (both views)
 #   - removes the Defender path exclusion for the install directory
 #   - deletes the install directory and the ProgramData data/log tree
@@ -20,6 +21,10 @@ param(
 	[string] $ServiceName = "ShopDbEndpointAgent",
 	[string] $TrayExeName = "shopdb-endpoint-tray.exe",
 
+	# Scheduled task that runs the user-context probe in the operator's session.
+	# Must match the installer's -UserContextTaskName.
+	[string] $UserContextTaskName = "ShopDB user-context probe",
+
 	# Also remove any server TLS certificate the site-agent installer imported
 	# into the machine Trusted Root store. Off by default because a root cert is
 	# shared trust material: only pull it when you are sure no other service on
@@ -113,6 +118,34 @@ Start-Sleep -Seconds 1
 # 3. Remove the tray logon Run key entry (both views) and the credential hive.
 Write-Host "[3/6] Removing registry entries ..."
 Remove-HklmBothViews -SubKey "SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name "ShopDbEndpointTray"
+
+# Unregister the probe task. Left behind it would keep firing at every logon
+# against a deleted exe, which shows up as a recurring task-failure history on a
+# machine nobody believes has the agent on it any more.
+try {
+	if (Get-ScheduledTask -TaskName $UserContextTaskName -ErrorAction SilentlyContinue) {
+		Unregister-ScheduledTask -TaskName $UserContextTaskName -Confirm:$false -ErrorAction Stop
+		Write-Host "  removed scheduled task '$UserContextTaskName'"
+	}
+	else {
+		Write-Host "  scheduled task '$UserContextTaskName' not present."
+	}
+}
+catch {
+	Write-Warning "  could not remove scheduled task '$UserContextTaskName': $($_.Exception.Message)"
+}
+
+# The install's one-shot tray launcher is transient and normally removes itself,
+# but an install that failed partway can leave it behind.
+try {
+	if (Get-ScheduledTask -TaskName "ShopDB tray first launch" -ErrorAction SilentlyContinue) {
+		Unregister-ScheduledTask -TaskName "ShopDB tray first launch" -Confirm:$false -ErrorAction Stop
+		Write-Host "  removed leftover scheduled task 'ShopDB tray first launch'"
+	}
+}
+catch {
+	Write-Warning "  could not remove scheduled task 'ShopDB tray first launch': $($_.Exception.Message)"
+}
 Remove-HklmBothViews -SubKey "SOFTWARE\GE\ShopDB"
 
 # Remove the All-Users Start Menu shortcut the site-agent installer created.