A container reflects its config: restart-on for containers (04-ISSUES/009)

A container reads a mounted file once, at start; its spec (image, env, volumes)
does not include a mounted file's content, so a settings change that re-renders the
file left the running process holding the old value while every check passed. Give
Container the restart-on field a Service already has, and recreate the container
when a named resource changed this pass. Unit-tested (recreated on change, left
alone otherwise) and proven in the mesh-lab: a running grafana runtime picked up a
token change on the next push.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

internal/declaration/declaration.go

@@ -462,6 +462,16 @@ type Container struct {
 	// and guessing an address that works from inside a container, which is the same thing with a
 	// worse failure mode.
 	Network string `json:"network,omitempty"`
+
+	// RestartOn names resources whose change means this container must be recreated — the same
+	// field a service has, for the same reason (novox/hq 04-ISSUES/009). A container reads a
+	// mounted file once at start; a changed file leaves the running process holding the old value,
+	// while every check passes because the file on disk is right. The container's spec — image,
+	// env, volumes — does not include a mounted file's *content*, so a settings change that
+	// re-renders that file is invisible to the ordinary spec diff. This closes that: the host
+	// recreates the container when one of these resources changed this pass, even if the spec
+	// matches.
+	RestartOn []string `json:"restart-on,omitempty"`
 }
 
 func (c *Container) Identity() string { return c.ID }