Report mapped drives from both Windows sources, worse status wins

Windows exposes mapped drives twice and the two views disagree. Captured on one
box at one moment, same two mappings: Get-SmbMapping reported OK for both while
net use reported Disconnected and Reconnecting. Collecting only Get-SmbMapping -
the nicer, more structured one - would have reported a healthy Q: on a machine
whose Q: was down, which is the exact failure this telemetry exists to catch.

So collect both and keep them apart. The probe emits netuse and smbmapping as
separate keys and does not reconcile them; the disagreement is the signal and
normalising it in the agent would discard it before anyone could see it.

The server merges by drive letter and shows the WORSE of the two. A drive that
either source calls broken is broken for the operator, and a drive neither
source gave a status for renders as Unknown rather than blank - an unannotated
row reads as healthy, so a failed check would present as a working drive.
Drives seen by only one source are kept, not dropped: Get-SmbMapping is absent
on some builds and session types, and requiring agreement would silently hide
every mapped drive on those machines.

No active reachability testing. Windows already knows the status, so touching
each share would be wasted work and would reintroduce the hang risk the bounded
probe exists to avoid.

The probe stays unelevated in the operator's session. UAC token separation
gives an elevated context a different mapped-drive table, often empty, so
elevating this later would quietly empty the card.

Adds a commented-out remap_drive seam in the command catalog. Not implemented,
but placed so the next person finds the user-session and elevation constraints
before writing it rather than after.

The merge logic has no test coverage yet; the docstring names the three
behaviours that must not be broken.

plugins/endpoints/commands.py

@@ -102,6 +102,27 @@ COMMAND_ALLOWLIST = {
 }
 
 
+# Reserved seam - one-click mapped-drive remediation. NOT implemented; this is a
+# placement note so the next person adds it here rather than inventing a new
+# transport. When it lands it will re-establish a Disconnected mapping surfaced
+# by the user-context card:
+#
+#     'remap_drive': {
+#         'label': 'Reconnect mapped drive',
+#         'description': 'Re-establish a disconnected network drive mapping.',
+#         'targetkind': 'drive',
+#     },
+#
+# It MUST execute in the interactive USER session. A SYSTEM-context remap creates
+# a mapping in SYSTEM's own drive table that the operator cannot see, so the card
+# would keep reporting the drive as broken while the "fix" silently succeeded
+# somewhere nobody is looking. An ELEVATED remap fails the same way, because UAC
+# token separation gives the elevated context a different drive table - the same
+# reason the probe itself runs unelevated from the tray.
+#
+# CommandExecutor.RunScriptInUserSession is the existing path for this.
+
+
 # Actions that demand a permission stricter than the base endpoints.command.
 # The enqueue route requires the caller to ALSO hold the mapped permission, so a
 # destructive action (a remote reboot) is a heavier grant than a routine toggle.