#1240 Job-level labels: block is silently ignored, not rejected

labels: and target: are step properties. Putting a labels: block on a job — the natural guess, since a job is the unit you'd think of as "placed" — passes swamp workflow validate with zero errors and zero warnings, and is then silently dropped. Every step runs locally.

Confirmed on 20260718.014016.0-sha.93325715.

Reproduction

No worker or swamp serve needed — the contrast shows up on a plain local run. Two workflows, identical except for where the labels: block sits.

Variant A — block on the job:

jobs:
  - name: placed
    labels:
      fb28: probe
    steps:
      - name: echo
        task:
          type: model_method
          modelIdOrName: fb28-probe
          methodName: execute
          inputs:
            run: echo "hello"

Variant B — same file, block moved onto the step (under name: echo).

Results:

Variant B's error is exactly right, and is what makes A's silence conspicuous by comparison:

Step requests remote placement but no worker dispatcher is active — remote
execution requires running under 'swamp serve' with enrolled workers

The job schema has no labels property; the key is simply accepted and dropped.

Why this matters

Anything relying on placement for isolation — running untrusted or third-party code away from the orchestrator, keeping credentials off a particular host — fails open here. The work lands on the orchestrator and nothing in validate, the run output, or the logs says so.

It also manufactures false negatives in security testing. We hit this while verifying issue #1239 (a separate secret-redaction bug): the job-level form produced a run where the "remote" step was masked and looked correct, because it had quietly executed locally. The test passed and the finding was invisible until we moved the block one level down.

Ask

Reject unknown job keys in validate, or emit a warning naming the offending key — ideally pointing at the step-level form, the way the placement error above already does so well.