One fix, no new command and no change to the piped output of the parity cases.

Fixed

• A first lo kubehz deploy with agent: operator finds its identity Secret. The live agent mounts the Secret kubehz-agent, which only the heartbeat CronJob's bootstrap creates, on its next five-minute tick. A first deploy that waited for the rollout alone lost that race about half the time: the live agent's pod stayed in ContainerCreating (the Secret volume did not mount) until the tick, and the deploy reported "the live agent was accepted but never became Ready". When the Secret is absent, the deploy now runs the CronJob's bootstrap once as a one-off Job (kubehz-heartbeat-bootstrap-<unix>-<random>), waits for that Job to complete, checks the Secret, deletes the Job and then applies the live agent (#230). Both implementations carry the change.

Changed

• Only a NotFound answer starts the bootstrap. A Secret read that fails for another reason (RBAC, an unreachable apiserver) stops the deploy with the read's message and applies no live agent.
• Every stop of the bootstrap says what the other stops say: the CronJob agent carries the live owner and does not beat, the live agent was not applied, so the cluster reports nothing until the re-run. A Job that did not complete stays for describe and logs.
• A fourth wait, KUBEHZ_IDENTITY_BOOTSTRAP_SECONDS (150 s), joins the three deploy waits in the CLI reference. The kubehz guide names the one-off Job.

Upgrade

Nothing to do. An existing cluster has its Secret and skips the bootstrap at its next lo kubehz deploy.