findUnescapedVars only walked parsed Commands strings, so a literal ${VAR}
in a step name, top-level comment, or environment: value - all outside any
commands: string - passed the check clean while Woodpecker's own ${VAR}
substitution pass (which runs over the entire raw pipeline YAML text, not
just command bodies) hard-failed the pipeline at compile time.
Add findUnescapedVarsInFile as a whole-file pass alongside the existing
per-command scan, deduped against it so nothing inside a commands: string
gets reported twice. Fixesoleks/pipetree#13, reproduced by a fixture
matching the actual incident: an explanatory comment above a step's
commands: block containing unescaped ${VAR} example text (oleks/deals
pipelines #12/#13, oleks/element-web-patched #5/#6).
Oleks