[VM Discovery P6] Content pack v1 + signing/publish pipeline

[mayankpande88]

Part of epic: nudgebee/nudgebee-enterprise#35404.

What we're building, in one sentence

The real production content pack — the exact list of commands the forager runs on customers' VMs — plus the pipeline that signs it, publishes it, and controls who gets which version.

(#113 builds the engine that runs packs, using a small hand-written test pack. This ticket writes the real one and productionizes distribution.)

Part 1 — The linux-inventory pack itself

One collector set per OS family; every command is read-only and runs as the unprivileged nudgebee-ro user:

Collector	Family	Command
os-release	all	cat /etc/os-release
identity	all	cat /etc/machine-id; cat /sys/class/dmi/id/product_uuid (readable-if-permitted, degrade gracefully); hostname -f; ip -o link
pkgs-rpm	RHEL-like, SUSE	rpm -qa --qf '%{NAME}\t%{EPOCH}\t%{VERSION}\t%{RELEASE}\t%{ARCH}\t%{INSTALLTIME}\n'
pkgs-dpkg	Debian-like	dpkg-query -W -f '${Package}\t${Version}\t${Architecture}\t${db:Status-Status}\n'
pkgs-apk	Alpine	apk info -v
subscription	RHEL	subscription-manager status; subscription-manager identity
subscription	Ubuntu	pro status --format json
subscription	SUSE	SUSEConnect --status-text
repos	RHEL-like	dnf repolist (or yum repolist -q on old hosts)
repos	Debian-like	cat /etc/apt/sources.list /etc/apt/sources.list.d/* 2>/dev/null
reboot-pending	Debian-like	test -f /var/run/reboot-required && echo yes || echo no
reboot-pending	RHEL-like	dnf needs-restarting -r; echo rc=$? (if installed)

Families: RHEL-like = CentOS 7/Stream, RHEL 7–9, Rocky, Alma, Oracle, Amazon Linux · Debian-like = Ubuntu 18.04–24.04, Debian 10–12 · SUSE = SLES 12/15, Leap · Alpine 3.x.

Every command must be verified on the oldest supported release of its family (CentOS 7 and Ubuntu 18.04 are the usual breakers — e.g. old dnf absent, pro absent).

Part 2 — Publish pipeline

• Packs live in a versioned directory in this repo (or a dedicated one — decide in the ticket).
• CI signs each released pack version with the existing Ed25519 trust root (same key infrastructure as action signing) and publishes it.
• Distribution channel — open decision (+ customer question): forager fetches over HTTPS from the cloud API, vs pushing packs down the existing relay WSS channel. HTTPS is easier to cache/CDN; relay keeps everything on one channel.

Part 3 — Version control per tenant

Content is an update surface too — the 2024 CrowdStrike outage was a content update that bypassed customers' binary version pinning. So, server-side:

• A tenant can pin a pack version; a pinned tenant never receives anything newer until unpinned.
• New versions roll out by ring: internal → early tenants → everyone. A version reaches ring 1 only after ring 0 ran it cleanly.

Acceptance criteria (each is a test)

• Pack runs cleanly against a matrix of: CentOS 7, RHEL 9, Ubuntu 18.04, Ubuntu 24.04, Debian 12, SLES 15, Alpine 3.x — every collector either succeeds or degrades with a recorded reason (never a hang, never garbage).
• CI produces a signed pack; forager accepts it; a manually-edited pack is rejected.
• Pinned tenant stays on its version while others advance.
• Rollout: version reaches ring 0, is observed, then ring 1 — verified in staging.

Design: docs/design/vm-discovery-phase0.md §6–§7 (PR #117).