feat: Deploy authenticated status receiver on isolated host and activate controller outbound HTTPS reporting

[Nickfost]

Goal

Deploy the existing authenticated status receiver on a small dedicated host that remains available when a controller is offline, then activate outbound HTTPS reporting on the controller without changing runner lifecycle or capacity.

Scope

• package the merged receiver for a dedicated unprivileged systemd service bound to loopback behind an existing HTTPS reverse proxy
• define clean installation, idempotent rerun, verification, upgrade, rollback, retention, and outage-isolation procedures
• provision per-controller signing material and a separate read credential out of band; store only host-local path references in configuration
• activate the existing reporter through reviewed private configuration while preserving controller identity, labels, runner group, capacity, resource limits, scale-to-zero behavior, and disabled SSH
• validate authenticated ingestion and read-only access, controller isolation, replay/freshness and payload bounds, restart behavior, retention, redaction, and receiver outage isolation

Boundaries

• receiver is separate from every runner controller and has no Docker socket, runner credential, deployment credential, or inbound connection to a controller
• controller traffic is outbound HTTPS only
• no WebUI and no mutation API
• no runner-capacity change
• no credentials, private endpoints, host inventory, or infrastructure identifiers in this public issue
• provisioning and deployment require separate authorization; preparation PRs remain draft and unmerged

The reporting implementation is complete in #62 / #63; this issue tracks deployment only.

[Nickfost]

Deployment preparation drafts:

• public receiver packaging, hardening, health, installer, tests, and runbook: feat: prepare status receiver deployment #67
• private controller engine-pin and activation-boundary preparation: a reviewed private desired-state change

The next unused VM/LXC ID could not be verified from repository or issue state, and this session did not access the hypervisor. Live inventory verification remains the first separately authorized provisioning prerequisite. No host, endpoint, secret, controller, capacity, or deployment change has been made.

[Nickfost]

Status: PR #67 remains draft and unmerged. The latest implementation head a72a947 passes the full GitHub Actions workflow, and all current review threads are resolved, but the bounded third new Codex review found valid blockers; their fixes are therefore not covered by a clean exact-head Codex review. The review gate remains closed. No receiver deployment, infrastructure change, credential work, or reporting activation was performed.

[Nickfost]

Repository preparation is complete:

• Public receiver/reporting support merged in feat: prepare status receiver deployment #67 (b76aefe668f07904e1a782fa5b779b606d6a44c9).
• Private preparation-only policy merged in a reviewed private desired-state change (e053239f52269129bdd2ffaed668c09e02790d19): active fleet.json remains unchanged, the current engine remains selected, and status_reporting remains absent.

No receiver deployment, controller reconciliation or engine upgrade, status-reporting activation, endpoint or signing-material provisioning, SSH change, capacity/resource change, or infrastructure change occurred.

[Nickfost]

[lane-a:phase2:issue-66-audit]

Current-default-branch audit confirms that safe repository preparation is complete in merged PR #67. The mocked status-receiver install/upgrade/check/rollback fixture passes (STATUS_RECEIVER_INSTALL_TESTS_OK), all 28 receiver tests pass, all 20 health/reporting isolation tests pass, and the documentation link check passes.

The issue remains open because its remaining acceptance is deployment-only and external to repository work: a separately authorized isolated host, out-of-band signing/read credentials, existing HTTPS reverse-proxy configuration, reviewed controller activation, and live ingestion/outage/rollback evidence. This audit performed no provisioning, secret work, controller reconciliation, capacity change, host mutation, or production deployment.