k3os config.yaml applies locally but k3s joins with stale token on production cold boot

Symptom

A cloud-init-style config.yaml that provisions SSH keys, network settings, and a k3s token works when iteratively rebooted on a local VM, yet the same configuration causes k3s agent nodes to join with an outdated token on first production cold boot.

Context

k3os processes /var/lib/rancher/k3os/config.yaml (or a boot-time datasource) during early boot stages. The config writes connman network files, populates authorized_keys for the rancher user, and sets the k3s token used by the bundled k3s binary. Because k3os has no in-place config reload, a local test cycle that reboots after the OS is already installed can mask a race where k3s starts before the config stage writes the token.

Production environments often differ in datasource (cloud metadata vs. kernel cmdline vs. remote URL), network bring-up timing (DHCP on isolated VLANs), and install mode (live ISO vs. k3os.install to disk). The k3s version is pinned to the k3os release, so a token generated against a different server version will also fail silently.

Open questions

1. Which boot-stage ordering guarantees that the token from config.yaml is present before the k3s systemd unit starts on a cold disk install?
2. How can the effective config consumed at boot be captured and diffed between the local VM and a production node without an interactive session?
3. Given the project's archived status, what migration path preserves the current config contract while moving to a maintained OS (Elemental, SLE Micro, or generic Linux + k3s)?