fix(fleet): route remote update trigger through getProxyTarget (#1123)

POST /api/fleet/nodes/:id/update and POST /api/fleet/update-all read
node.api_url + node.api_token directly, so a pilot-agent row (which
carries neither) returned "Remote node not configured." and was
filtered out of bulk update. Both routes now resolve the target via
NodeRegistry.getProxyTarget(), which returns the loopback URL for an
active pilot tunnel and the configured api_url for proxy-mode remotes.
fetchMetaForNode replaces the direct fetchRemoteMeta call for the
self-update capability check.

self-update is removed from PILOT_DISABLED_CAPABILITIES so a
Compose-deployed pilot can advertise it; the host-console filter
stays. SelfUpdateService still gates the local-end capability on the
container actually carrying docker-compose labels, so a docker-run
pilot self-disables and the Fleet UI sees a clean 503 instead of an
ambiguous failure.

Tests: new fleet-pilot-update covers the four single-node branches
(success via loopback, null target, no self-update capability, meta
offline) and two update-all cases (mixed-fleet dispatch, all-targets-
null skip). capability-registry-pilot rewired to assert the new
filter set.

backend/src/services/CapabilityRegistry.ts

@@ -101,10 +101,14 @@ export function getActiveCapabilities(): readonly string[] {
  * the central->pilot path for them is not yet wired through the reverse tunnel.
  * Surfacing them would let the frontend offer a tab whose click silently falls
  * through to central's local handler.
+ *
+ * `self-update` is intentionally NOT here: a pilot deployed via Docker Compose
+ * picks up the compose labels SelfUpdateService.initialize() needs and toggles
+ * the capability on locally; the Fleet Update flow then routes through
+ * NodeRegistry.getProxyTarget() so the tunnel carries the trigger.
  */
 const PILOT_DISABLED_CAPABILITIES: readonly Capability[] = [
   'host-console',
-  'self-update',
 ];
 
 /** Disable capabilities that require a central->pilot path that is not yet wired. */