#189 swamp model method run: --foreach to fan out across instances

Problem

swamp data list <model> --content (shipped in commit 0c2de8d) now collapses N×data get into one call. There's no equivalent for running a method across every instance of a model, and agents still fan out:

swamp model method run X-deployment getRolloutStatus --input deploymentName=auth
swamp model method run X-deployment getRolloutStatus --input deploymentName=api
swamp model method run X-deployment getRolloutStatus --input deploymentName=metrics
swamp model method run X-deployment getRolloutStatus --input deploymentName=frontend

…then again for diagnoseService × N services, getWarnings, verification re-checks, etc.

On a recent agent benchmark (k8s-debug-v2, 5 cold-start runs):

Even the fast runs spend 11-22 dispatches per benchmark fanning out the same method over multiple instances of one model. With ~0.24 s startup per dispatch (after the telemetry-detach fix in 95ebaf0), that's 3-5 s of pure overhead per run, plus the agent reasoning time between each call.

Proposal

Extend swamp model method run with a --foreach flag:

# Run the method on every instance of the model:
swamp model method run X-deployment getRolloutStatus --foreach

# With per-iteration input templating:
swamp model method run X-deployment getRolloutStatus \\
  --foreach \\
  --input-template 'deploymentName={instance.name}'

# Custom iteration source (a query over the data store):
swamp model method run X-deployment getRolloutStatus \\
  --foreach 'tags.workflow == \"debug\"' \\
  --input-template 'deploymentName={data.attributes.name}'

Semantics:

• Default --foreach (no argument) iterates over the model's declared resource instances.

• Optional CEL predicate as the foreach argument — same syntax as swamp data query.

• --input-template accepts a string with {instance.X} / {data.attributes.X} placeholders.

• The CLI handles parallelism (default = 5 concurrent, configurable with --parallelism N).

• Output is a single JSON envelope:

  {
    \"foreach\": \"\",
    \"iterations\": 4,
    \"succeeded\": 4,
    \"failed\": 0,
    \"results\": [
      { \"instance\": \"auth\", \"status\": \"succeeded\", \"dataArtifacts\": [...] },
      ...
    ]
  }

Alternative — encourage extension authors to ship batch methods

Already partially done for @john/k8s (added namespace.health that aggregates pod/deployment/service/event status into one call, commit ad9b... in the extension repo). But:

• Every extension author has to think of every fan-out worth packaging.
• Some fan-outs are too specific to be worth a dedicated method.
• The CLI flag generalises to any model.

Both are useful: extension-authored batch methods produce cleaner structured output when the author thinks of them; the --foreach flag covers the long tail.

Why this matters

Per-bench impact (5 runs, k8s-debug-v2):

• Mean model method run calls per run: 14.4
• If half of those are batchable: ~7 calls saved per run.
• ~7 turns × 0.24 s = ~1.7 s pure dispatch saved per run.
• Plus the agent reasoning between each call (typically 1-3 s).
• Total: ~5 s × 5 runs = 25 s per bench batch, plus the cleaner context budget.

Stacks on top of the wins from #01 (workflow run summary), #02 (data list --content), and #07 (telemetry detach).

Tracked alongside lab/186 (workflow-time instance creation) and lab/187 (CLI startup latency, partially addressed) as the agent-efficiency arc.