Deep Review: 20260415-184413-pr-315

			Valid property names and types are derived from the App CRD at
			runtime. If the App resource does not exist, it is created with
			default settings before applying the specified values.

			By default, rdd set waits for the App's Settled condition
			to reach True at the new generation. The wait covers every
			property change and returns only after the full reconcile
			chain catches up. Pass --wait=false to return as soon as
			the patch is accepted, or --timeout=0 to wait indefinitely.

			Examples:
			  rdd set running=true
			  rdd set running=true containerEngine.name=containerd
			  rdd set kubernetes.enabled=true kubernetes.version=1.32.2

This help text describes the old per-property wait behavior. The implementation now waits for Settled=True unconditionally, and the design docs (docs/design/cmd_app.md:13) reflect the new behavior. The cobra help was not updated.

Valid property names and types are derived from the App CRD's OpenAPI schema at runtime, so the command automatically supports new properties as they are added to the CRD.

If the App resource does not exist, it is created with default settings before the specified values are applied.

By default, `rdd set` waits for the reconcile chain to settle before returning. Every property change — `running`, `containerEngine.name`, `kubernetes.enabled`, or any combination — waits for the App's `Settled` condition to reach `True` with `ObservedGeneration` matching the post-patch generation.

`Settled` goes `False` whenever the App controller sees a generation it has not yet caught up with, and back to `True` once the LimaVM has reached a terminal phase (Started or Stopped) and the engine controller has processed the current generation.

The `ObservedGeneration` filter prevents a stale `Settled=True` from a previous reconcile from prematurely satisfying the wait.

Fix: update the Long help to describe the Settled-based wait.

When a spec change updates the template ConfigMap (e.g. kubernetes.version), the App controller patches the ConfigMap and requeues. On the requeue it mirrors LimaVM conditions, which still carry Running=True/Started because the LimaVM controller has not yet detected the template change. If the engine controller has already stamped ContainerEngineReady at the new generation (it just re-confirms its existing connection), computeAppConditions sees a terminal Running reason with a current-generation engine condition and sets Settled=True.

This can cause rdd set to return before the VM restarts with the new config.

Mitigating factors: the previous code never waited for non-running property changes (the explicit TODO this commit addresses), so the new behavior is strictly better. The window is narrow — the LimaVM controller detects template changes quickly via handleTemplateUpdate and sets restartNeeded, which changes Running and causes a subsequent App reconcile to correct Settled. In practice, this race requires the engine reconcile and App requeue to both complete before the LimaVM controller processes the ConfigMap watch event.

Fix: the App controller could check whether the LimaVM's observedTemplateResourceVersion matches the current ConfigMap's resourceVersion before allowing Settled=True, but this adds cross-controller coupling. A simpler approach: return ctrl.Result{RequeueAfter: ...} instead of Requeue: true after the template patch, giving the LimaVM controller time to process.

	case engineCond.Status != metav1.ConditionTrue:
		settled.Status = metav1.ConditionFalse
		settled.Reason = engineCond.Reason
		settled.Message = engineCond.Message
	default:
		settled.Status = metav1.ConditionTrue
		settled.Reason = "Settled"
		settled.Message = "App has reached the desired state"
	}
	return settled
}

// runningLimaVMMessage builds the Settled message when LimaVM's
// Running reason does not match the desired state. Failure reasons
// (ending in "Failed") propagate LimaVM's diagnostic message; other
// reasons get a concise "has not yet reached <desired>" text.
func runningLimaVMMessage(runningCond *metav1.Condition, desired string) string {
	if strings.HasSuffix(runningCond.Reason, "Failed") && runningCond.Message != "" {

When the reason is a terminal failure like StartFailed, the message "has not yet reached Started" implies progress that will not happen. The Reason field carries the correct signal, but rdd set users see only the timeout error and need to inspect the condition separately.

Fix: propagate the upstream message for failure reasons:

-		settled.Message = "LimaVM has not yet reached Started"
+		if strings.HasSuffix(runningCond.Reason, "Failed") {
+			settled.Message = runningCond.Message
+		} else {
+			settled.Message = "LimaVM has not yet reached Started"
+		}