[delivery]: harden runtime daemon launch away from dist-only dependency

[svelderrainruiz]

Summary

The stacked live replay with LabVIEW-Community-CI-CD#1825 and LabVIEW-Community-CI-CD#1826 proves the unattended manager now gets far enough to launch the runtime daemon through systemd, but the daemon process is still started from dist/tools/priority/runtime-daemon.js. Fresh clean proof lanes do not carry that built artifact, so the daemon dies before worker checkout begins.

Live Evidence

• stacked proof lane: E:/comparevi-lanes/1826-stacked-proof
• runtime dir: tests/results/_agent/runtime-1826-stacked-live
• manager status now reports a real daemon PID before exit
• daemon log tail ends with:
  Error: Cannot find module /mnt/e/comparevi-lanes/1826-stacked-proof/dist/tools/priority/runtime-daemon.js

Why This Matters

This is now the next honest blocker ahead of worker checkout base-ref proof. The daemon launch path needs the same current-source or deterministic fallback hardening that the detached manager path already got.

Acceptance

• runtime daemon launch works from a clean proof lane without requiring a prebuilt dist artifact
• live unattended replay advances past runtime-daemon module loading
• [delivery]: resolve runtime worker checkout base ref in canonical clones compare-vi-cli-action#1826 can then be revalidated against the real worker checkout path

[svelderrainruiz]

Opened against the fork by mistake while replaying a stacked proof lane. Recreated in the canonical upstream repository so the delivery control plane stays authoritative there.