Unknown keys in rule YAML are silently ignored (e.g. ignore vs ignores) #2963

Summary

A rule YAML accepts unknown top-level keys without any diagnostic. A typo in a key name therefore changes behaviour silently instead of failing.

In our case ignore: (singular) was written where ignores: was meant. The exclusion was dropped, and the rule began reporting the files it was configured to skip. Because nothing is printed, the natural conclusion was "the ignore field does not work here", and the exclusion was reimplemented in a shell wrapper around ast-grep scan. That duplicate lived on until the two copies drifted apart.

Reproduction

ast-grep 0.45.3 (also reproduced on 0.42.3), macOS arm64.

sgconfig.yml

ruleDirs:
  - rules

rules/r.yml

id: ban-foo
language: TypeScript
severity: error
message: foo is banned
rule:
  pattern: foo()
files:
  - "src/**/*.ts"
ignores:          # <- vary this key
  - "**/*.test.ts"

src/a.ts and src/a.test.ts both contain foo();. Run ast-grep scan.

Expected

An unknown key in a rule YAML should be surfaced, either as an error (serde deny_unknown_fields) or as a warning naming the file, the offending key and the closest valid key.

For a linter an error seems the safer default: a dropped ignores makes the tool report violations it was configured not to report, and a dropped files would silently widen the scan. If tolerating extra keys is needed for compatibility, a warning with an opt-in strict mode would still remove the footgun.