A one-shot service that finished is not stopped, and a container is what it reads

Two faults that both reported success while being wrong, found while proving
the firewall module actually delivers.

A unit whose job is to apply something and exit — load a rule set, set a
sysctl — is inactive the instant it succeeds. Reading that as stopped made it
permanently unsatisfiable: the host started it, it worked, the host read back
stopped and reported the machine as not doing what it was told, on every apply,
for ever, with the rules correctly in place the whole time. That is what the
firewall has been doing on every machine it was assigned to, and why the
four-machine bed was red.

And a container took its identity from its own fields, not from the files it
reads. A file written in an earlier apply — or before the container declared it
as a dependency — left a process holding a credential the mesh had already
replaced, with everything reporting success (novox/hq 04-ISSUES/045). What a
container reads is now part of what it is, so the comparison is a standing one
rather than a tripwire that fires during one apply and never again.

internal/apply/schedule.go

@@ -107,7 +107,10 @@ func (s *Scheduler) Sync(d *declaration.Declaration) {
 		}
 		seen[c.Identity()] = true
 
-		spec := containerSpec(c)
+		// Nothing to read: a scheduled container may not declare restart-on — it runs to completion
+		// on its cadence rather than staying running to be restarted — so its identity cannot
+		// depend on another resource's content and there is nothing to pass.
+		spec := containerSpec(c, nil)
 		if existing := s.jobs[c.Identity()]; existing != nil && existing.spec == spec {
 			// Unchanged: keep where it is in its cadence, refresh the declaration pointer only.
 			existing.container = c