#1415 Include a workflow's declared `inputs` in `workflow get --json` (and a `hasInputs` hint in `workflow search --json`)

Type: feature / JSON API gap Reproduced with: swamp 20260726.012317.0-sha.2231d3d9 (also seen on 20260724.191435.0-sha.10943ef5)

Summary

A workflow declares its inputs in full — types, defaults, descriptions, and which are required — but none of it appears in either JSON reader. The declaration is recoverable only by reading the workflow YAML at path, which is not possible for a client talking to a remote orchestrator over the socket.

A workflow declares inputs properly

inputs:
  properties:
    labelKey:
      type: string
      default: role
      description: Label key to select on.
    labelValue:
      type: string
      default: ""
      description: Label value; omit to target everything.
    refresh:
      type: boolean
      default: true
      description: Refresh metadata first.
  required: []

Neither JSON reader returns any of it

swamp workflow get <workflow> --json
# → {id, name, description, version, jobs[], path}   — no inputs (also no tags, no reports)

swamp workflow search --json
# → results[] = {id, name, description, jobCount}     — no inputs, no hasInputs

workflow schema get is the schema for workflow files, not for a given workflow's inputs, so there is no third place to look.

Impact

Any tool that wants to present or prompt for a workflow's inputs — a UI, a wrapper CLI, a scheduler — can describe a workflow only as a name, a description, and a job count. Without the input schema it must either:

• launch every workflow on its declared defaults with no way to override them — and for an input like labelValue: "" meaning "everything", that silently selects the broadest possible target; or
• invent form fields it cannot validate against the real declaration.

Parsing the YAML at path is not a workaround for a remote caller: the file is on the orchestrator host, not the client's.

Ask

• Include inputs (the full properties map with types, defaults, descriptions, and required) in swamp workflow get --json.
• Optionally, add a required/hasInputs hint to swamp workflow search --json so a list view can flag which workflows take parameters without an N+1 round-trip.

Bonus: workflow get --json also omits tags and reports, which are likewise declared in the file but unreadable over the socket — including them in the same pass would close the broader "the JSON reader is lossy versus the file" gap.