fix(validation): allow Design Guide filter suffixes in parameter casing

[hdamker]

What type of PR is this?

bug

What this PR does / why we need it:

camara-parameter-name-casing-convention in the r4 ruleset (linting/config/.spectral-r4.yaml) requires query/path parameter names to match ^[a-z][a-zA-Z0-9]*$, with no allowance for the filtering-operation suffixes the Design Guide §4.3.2 requires (.gte, .gt, .lte, .lt). Any spec following the Design Guide's own filtering examples verbatim (e.g. creationDate.gte) gets a false-positive warning.

Fix: the pattern now allows those four suffixes as an optional exact tail — ^[a-z][a-zA-Z0-9]*(\.(gte|gt|lte|lt))?$. The base name still has to be lowerCamelCase, and an unrecognized suffix or a badly-cased base name still gets flagged. Scoped to the r4 ruleset only — .spectral-r3.4.yaml doesn't define this rule.

Which issue(s) this PR fixes:

Fixes #388

Special notes for reviewers:

Added test coverage in validation/tests/test_spectral_gap_rules.py: all four suffixes passing, an unrecognized suffix still failing, and a badly-cased base name with a valid suffix still failing. Full validation/tests/ suite (1216 tests) passes locally.

Changelog input

release-note
Fixed a false-positive warning from the r4 parameter-casing rule on query parameters using the Design Guide's filtering-operation suffixes (.gte, .gt, .lte, .lt).

Additional documentation

This section can be blank.

docs

[rartych]

LGTM