Integrate cleanup into pipeline execution

docs/policy/architecture.md

@@ -185,8 +185,8 @@ availability.
 Writes, moves, replacements, and deletions must use narrow, explicit,
 root-confined destinations. Symlinks, traversal, broad roots, and ambiguous
 relative destinations must not expand the scope of an operation. Cleanup is
-permitted only through explicit operator action or configured post-publish
-gates, and it must preserve durable cache unless cache removal is explicitly
+permitted only through explicit operator action or the configured final cleanup
+stage, and it must preserve durable cache unless cache removal is explicitly
 requested.
 
 Physical layout, retention, and operational lifecycle belong in
@@ -212,10 +212,16 @@ transaction boundary.
 
 Automatic local cleanup is permitted only after a successful publish commit,
 only when explicitly configured, and only through the path-safety guardrails.
-It is a durable local obligation bound to that committed run and its exact
-targets, not an inferred side effect of the current stage list. A cleanup
-failure makes the invocation incomplete while leaving the committed remote
-snapshot authoritative; later invocations resume the recorded obligation.
+It is the final ordinary pipeline stage after `notify`. The stage derives its
+exact run-scoped targets from validated publish metadata and the configured
+campaign/session identity; it never infers a target from directory contents or
+rereads remote storage. A cleanup failure makes the invocation incomplete while
+leaving publish succeeded and the committed remote snapshot authoritative. A
+normal later full run reuses valid upstream stages and retries cleanup.
+
+The standalone `publish` command selects only publish and therefore never
+invokes cleanup. Operators may select cleanup directly only when the manifest
+contains valid successful publication evidence.
 
 ## Security, Privacy, And Diagnostics