#4358 Docs: step concurrency caps only that step's forEach iterations, not its whole dependency level

swamp-club#4357 changes how step-level concurrency resolves. A step's concurrency now caps only that step's own forEach iterations and overrides the job and workflow values for them. It no longer throttles sibling steps in the same dependency level: two independent forEach steps in one job, each with concurrency 1, now run side by side. Steps that set no concurrency share the job value, or the workflow value when the job sets none. SWAMP_MAX_CONCURRENT_STEPS stays a ceiling on top.

Pages describing the old rule:

• content/manual/reference/workflows.md, step concurrency: says it is the maximum number of steps that execute in parallel at this step's dependency level within the job. It should say it caps this step's forEach iterations.
• content/manual/reference/workflows.md, job concurrency: should say it caps the steps that set no concurrency of their own.
• content/manual/reference/workflows.md, Concurrency Resolution Order item 1: says that when several steps at one dependency level set concurrency, the minimum value across them is used. Replace it with the per-step rule above.
• content/manual/explanation/the-workflow-execution-model.md: says each forEach iteration runs concurrently up to the job's concurrency limit. Add that a step's own concurrency takes precedence.