Restore Docker agents to Hosts inventory

docs/API.md

@@ -795,6 +795,12 @@ Returns scheduler health, DLQ, and breaker status. Requires `monitoring:read`.
 - `GET /api/diagnostics` (auth)
 - `POST /api/diagnostics/docker/prepare-token` (admin, `settings:write`)
 
+The Docker migration token request accepts `agentId`, optional `tokenName`, and
+optional `enableHost`. When `enableHost` is omitted, the generated token and
+install command enable both host and Docker monitoring so the machine appears
+in both Hosts and Docker. Set `enableHost` to `false` only for an intentional
+workload-only agent; that mode receives Docker-report scope only.
+
 ### Logs (Admin)
 - `GET /api/logs/stream` (server-sent stream)
 - `GET /api/logs/download` (bundled logs)

docs/release-control/v6/internal/subsystems/agent-lifecycle.md

@@ -3932,10 +3932,19 @@ the shared frontend Unix builder, instead of returning a raw `| bash -s --`
 pipeline that drifts from the lane's governed install shape.
 The same lifecycle shell-transport contract also applies to the diagnostics
 container-runtime migration install command in `internal/api/router.go`: that
-response must emit the canonical `--enable-host=false` flag and the governed
-root-or-sudo wrapper, rather than falling back to the stale `--disable-host`
-alias or a raw `curl | sudo bash` pipe that drifts from the managed install
-surface.
+response defaults to the native Unified Agent's host plus Docker modules,
+emits the canonical `--enable-host` flag, and uses a token scoped for host
+report/configuration continuity as well as Docker reports. An explicit
+`enableHost:false` request keeps the intentional workload-only path, the
+canonical `--enable-host=false` flag, and Docker-report-only token scope. Both
+modes must retain the governed root-or-sudo wrapper rather than falling back
+to the stale `--disable-host` alias or a raw `curl | sudo bash` pipe that
+drifts from the managed install surface.
+The Settings Docker / Podman install profile and the legacy
+`scripts/install-container-agent.sh` compatibility wrapper follow that same
+default: selecting Docker monitoring enables the Docker module without
+silently disabling the host module. Workload-only operation remains an
+explicit `--enable-host=false` choice through the canonical installer.
 That same diagnostics migration command must stay on the shared backend
 install-command helper path in `internal/api/agent_install_command_shared.go`,
 rather than rebuilding a local shell formatter in `router.go`, so optional

docs/release-control/v6/internal/subsystems/api-contracts.md

@@ -5776,7 +5776,14 @@ That same governed container-runtime migration response must also preserve the
 canonical lifecycle shell payload shape: `installCommand` in the diagnostics
 docker prepare-token response may not emit the stale `--disable-host` alias or
 an ad hoc `curl | sudo bash` pipeline, and must instead match the canonical
-root-or-sudo wrapped install transport with `--enable-host=false`.
+root-or-sudo wrapped install transport. Omitted `enableHost` defaults the
+native Unified Agent migration to host plus Docker monitoring and emits
+`--enable-host`; explicit `enableHost:false` preserves the workload-only
+variant and emits `--enable-host=false`.
+The Settings infrastructure operations model must expose the same default in
+generated install flags: its Docker / Podman profile enables Docker without
+adding a host-disable flag, while the generic flag translator continues to
+preserve an operator-supplied explicit host opt-out.
 That diagnostics install-command payload must also be assembled through the
 shared backend install-command helper in `internal/api/agent_install_command_shared.go`
 instead of a handler-local shell formatter, so token omission, plain-HTTP

docs/release-control/v6/internal/subsystems/deployment-installability.md

@@ -1328,6 +1328,17 @@ agent binaries, or installer signing material. The published self-hosted
 so official release images still carry signed installer and agent download
 assets, and any build that declares `PULSE_UPDATE_SIGNING_PUBLIC_KEY` must
 continue to fail closed unless the matching signing secret is mounted.
+The `agent_runtime` image is a Unified Agent deployment and defaults to both
+host and Docker modules (`PULSE_ENABLE_HOST=true`,
+`PULSE_ENABLE_DOCKER=true`). Operators may still set
+`PULSE_ENABLE_HOST=false` for an intentional workload-only deployment, but
+the image must not silently force that narrower mode and remove a previously
+reported machine from the Hosts surface.
+The legacy `scripts/install-container-agent.sh` compatibility wrapper must
+match that default by forwarding `--enable-docker --enable-host`; it may point
+operators who need workload-only behavior to the canonical installer's
+explicit `--enable-host=false` option, but must not choose that opt-out for
+them.
 That same update-runtime boundary now also owns bounded rollback retention and
 disk-space fail-closed behavior for self-hosted app updates. `internal/updates/`
 must prune stale retained rollback snapshots, clear history references when an

docs/release-control/v6/internal/subsystems/monitoring.md

@@ -91,6 +91,12 @@ downstream surfaces can warn, and it must clear on its own once only one
 machine keeps reporting for the window. Monitoring must not auto-split the
 collapsed identity: the machine ID is the identity key, and the remedy
 (regenerating the clone's machine-id) belongs to the operator.
+Unified Agent module projection is report-authored and additive. When one
+agent sends host and Docker reports for the same machine identity, monitoring
+must refresh one canonical machine carrying both facets so the Hosts and
+Docker typed views expose the same canonical ID. A deliberately Docker-only
+agent sends no host report and must remain absent from the Hosts view rather
+than gaining a synthetic host facet from Docker telemetry.
 Proxmox read-state rehydration is the inverse boundary: canonical
 unified-resource CPU metrics are 0..100 percentages, while legacy
 `models.Node.CPU`, `models.VM.CPU`, and `models.Container.CPU` remain Proxmox

docs/release-control/v6/internal/subsystems/performance-and-scalability.md

@@ -863,6 +863,10 @@ Default-org token scoping and notification-settings fan-out on shared
 `internal/api/router.go` are likewise adjacent only: the tenant-monitor
 settings inheritance hook runs once per tenant-monitor creation and changes
 no chart transport, downsampling, or polling behavior.
+Container-runtime migration mode selection on that shared router path is also
+request-local. Deriving the bounded host-plus-Docker or Docker-only token
+scope and matching install flag must remain constant work with no resource
+inventory scan, telemetry fan-out, or extra persistence pass.
 
 The bars / sparklines toggle and its sparkline-range picker on the
 WorkloadsSurface support page-level ownership through four optional

docs/release-control/v6/internal/subsystems/security-privacy.md

@@ -773,6 +773,12 @@ the visible API-token manager: agent install command tokens, deploy bootstrap
 tokens, enrollment runtime tokens, container runtime migration tokens, and
 first-run/regenerated admin tokens must use the same shared server-side owner
 setter rather than carrying owner identity in caller-controlled metadata.
+Container-runtime migration tokens must also follow the requested module
+boundary. The default host-plus-Docker migration may grant only the bounded
+Agent report, configuration-read, Agent-manage, and Docker-report scopes; an
+explicit `enableHost:false` workload-only migration must retain only the
+Docker-report scope. Neither path may gain command-execution or Kubernetes
+report authority implicitly.
 That same command-token trust boundary also owns first-use binding for
 Proxmox install-command tokens. `internal/api/agent_exec_token_binding.go` may
 persist `bound_agent_id`, `bound_hostname`, and `bound_at` only for

docs/release-control/v6/internal/subsystems/storage-recovery.md

@@ -3636,6 +3636,12 @@ That same shared dependency now also assumes those diagnostics install payloads
 route through the canonical backend install-command helper, so recovery-adjacent
 transport surfaces do not inherit handler-local drift in token omission,
 plain-HTTP `--insecure`, or trailing-slash normalization.
+The persisted migration token and returned install payload must describe the
+same module boundary: omitted `enableHost` atomically persists the bounded
+host-plus-Docker scopes before returning an enabled-host command, while an
+explicit false value persists only Docker-report authority before returning
+the workload-only command. A persistence failure must continue to fail the
+request rather than returning credentials whose scope contract was not saved.
 That same shared `internal/api/` dependency also assumes diagnostics memory
 source breakdowns backfill canonical fallback reasons even when a raw legacy
 snapshot reaches `internal/api/diagnostics.go` without one, so

docs/release-control/v6/internal/subsystems/unified-resources.md

@@ -17,6 +17,11 @@
 
 Own canonical resource identity, type normalization, typed views, and
 cross-source deduplication.
+One machine may belong to more than one typed view without becoming more than
+one canonical resource. A matching Pulse host report and Docker report merge
+into one `agent` resource with Agent and Docker facets, and the Hosts and
+Docker-host views must return that same canonical ID. A Docker-only resource
+keeps its `docker-host` contract type and is not admitted to the Hosts view.
 For Docker and Podman container resources, the canonical CPU metric represents
 host-capacity-normalized utilization. Runtime-native per-core CPU percent is
 kept on Docker metadata as raw evidence and must not replace the canonical