stacked-dev request_review hardcodes the retired `collective` CLI → review-notify fails on PATH-without-collective

[JoshuaBearup]

Summary

The request_review activity in the stacked-dev norn-worker example hardcodes an executable named collective to deliver reviewer-notification DMs. In the current Meridian ecosystem the collective CLI is retired (it was a v1 shim), so on any deployment without that binary on PATH the activity fails terminally and the whole stacked-dev run cannot reach review.

Found on a checkout at rev 6ffb6972 while running the standalone stacked-dev pipeline (3-process model: aion server + stacked-dev-worker-norn + an aion start driver) concurrently on a single node. Confirmed still present on main (default branch) at filing: handlers.rs:494 reads "collective".

Where

examples/stacked-dev/norn-worker/src/handlers.rs, in request_review (around line 494):

for reviewer in reviewers {
    require_run(
        shell,
        "collective",                       // <-- retired binary name
        &[
            "send",
            "--as", "Meridian",
            "--to", reviewer,
            "--subject", &format!("Review: {brief_id}"),
            "--message", &message,
        ],
        ".",
        &format!("collective send to {reviewer}"),
    )?;
}

The activity's own doc-comments also reference "via collective DM" (lines ~449/454).

Failure mode (observed)

With no collective on PATH, every parent fails at request_review:

terminal: collective send to <reviewer>: executable not found on PATH: collective

The stack is otherwise sound through provision → scout → warm → dev → gate; this is the first step that breaks. It's systemic — all concurrent parents fail at the same activity.

Fix we applied locally (works)

The replacement is the unified meridian message send, whose flags are identical — only the executable and an inserted message subcommand token differ:

-        "collective",
+        "meridian",
         &[
             "send",
+        &[
+            "message",
+            "send",
             ...

(i.e. meridian message send --as Meridian --to <reviewer> --subject "Review: <id>" --message <msg>.) Verified live — DMs land.

Suggested upstream fix

Rather than swap one hardcoded binary for another, the robust fix is to make the review-notify command/sender configurable per deployment, so a flow isn't pinned to a CLI name at all. This is closely related to #20 (no per-activity config surface for the messaging sender). If a hardcoded default is kept, meridian message send is the current correct one; collective should not be it.