#2344 serve: default placement for steps that declare none (so one workflow runs both locally and via workers)

Problem

Placement can only be declared in workflow YAML (workflow → job → step, src/domain/workflows/placement.ts). A step with effective placement throws when no dispatcher is active (method_execution_service.ts #executeRemotely). So one workflow file cannot both:

• run locally with swamp workflow run <wf> (single host, break-glass, dev), and
• be routed to a worker pool when the same repo is served by swamp serve.

--remote-only rejects placement-free steps; it does not route them. Nested workflows do not inherit the parent's placement, so a thin wrapper does not help either.

Reproduction (20260922.011324.0, fresh swamp repo init)

Two workflows, identical except that one has top-level labels: {pool: colo-ops}, each with one command/shell execute step:

$ swamp workflow run probe-none      # succeeds
$ swamp workflow run probe-placed
Failed workflow probe-placed in 53ms
Step requests remote placement but no worker dispatcher is active — remote execution requires running under 'swamp serve' with enrolled workers

Impact

A repo that already has hundreds of workflows run locally (ours has 352) cannot adopt serve plus workers gradually. It has two choices:

• edit every workflow, which breaks every local run including break-glass; or
• leave them without placement, in which case serve runs them on its loopback executor. Our orchestrator is a minimal container with no ssh or network reach, so they fail there.

Proposed

A serve-side default placement, applied only when a dispatcher is active and only to steps whose merged effective placement is empty. For example:

swamp serve --default-placement-label pool=colo-ops   # repeatable; env SWAMP_DEFAULT_PLACEMENT_LABELS

It sits under the workflow in the merge order. Explicit labels: {} still opts a step back to loopback, as documented. Local runs are unaffected because the default exists only in serve.

An alternative with the same effect: when no dispatcher is active, fall back to in-process for label-only placement, behind an opt-in workflow field (for example placementFallback: local).