hostname field in k3os v0.12.0 cloud-config requires two boots to apply

Goal: Ensure that the hostname specified in a k3os cloud‑config is available to the k3s service during the first boot so that nodes register with Rancher using the correct identifier without requiring a manual reboot or cfg apply.

Constraint: In k3os v0.12.0 the hostname key is handled by systemd‑hostname after network‑online.target, while k3s.service starts early and therefore sees the temporary 'k3os' hostname. The documented behavior notes that the hostname field is only honored on the second boot after a reboot or after running sudo k3os cfg apply, leaving the timing and supported work‑arounds unclear.

Questions:

• Can the k3s service be safely delayed until after the hostname unit completes without breaking other dependencies?
• Does adding a runcmd that executes hostnamectl set-hostname before k3s start provide a reliable, version‑stable workaround?
• Is there a supported cloud‑config mechanism (e.g., a different key or a post‑write hook) that applies the hostname on the first boot in k3os v0.12.0?