camara-reserved-words and camara-security-no-secrets-in-path-or-query-parameters custom functions never emit Spectral findings

[hdamker]

Describe the bug

The two custom Spectral rules camara-reserved-words (S-012) and camara-security-no-secrets-in-path-or-query-parameters (S-017) never emit findings because their implementing functions at linting/config/lint_function/camara-reserved-words.js and linting/config/lint_function/camara-security-no-secrets-in-path-or-query-parameters.js use console.log to report matches instead of returning the Spectral-required [{ message, path }] array. As a result Spectral produces no diagnostics when a reserved word appears in a path / operationId / security scheme / component name, and no diagnostics when MSISDN / IMSI / phoneNumber appear in path or query parameters.

Both rules are wired into linting/config/.spectral-r4.yaml with severity: warn and recommended: true but are effectively dormant.

To reproduce

1. Lint an API spec containing a path like /resources/list/{MSISDN} against .spectral-r4.yaml (or the equivalent r3.4 ruleset — same function wiring)
2. Observe: no camara-reserved-words finding for the list path segment, no camara-security-no-secrets-in-path-or-query-parameters finding for the MSISDN path parameter
3. Both rules' console.log output lands on stdout during the Spectral run but is never surfaced as a Spectral diagnostic

Expected behavior

Both rules emit warnings at the matched path — consistent with their declared severity: warn / recommended: true configuration.

Reference implementation

linting/config/lint_function/camara-array-items-description.js follows the correct Spectral custom-function contract: it pushes { message, path } entries into an errors array and returns that array. camara-reserved-words.js and camara-security-no-secrets-in-path-or-query-parameters.js should be rewritten to the same pattern.

Additional context

Discovered during validation-framework broken-spec regression work (branch 5 regression/r4.1-broken-spec-schema-constraints on camaraproject/ReleaseTest). The two rules were originally targets of the schema-constraints broken-spec branch; when no findings were produced for deliberately-triggering edits, investigation traced the cause to the missing return value. Both rules were dropped from the branch's scope; the branch's .regression/REGRESSION.md documents the exclusion.

Once the two functions are fixed, both rules can be pinned via regression branches. Two options:

• Extend the existing regression/r4.1-broken-spec-schema-constraints branch (the rules' originally intended home) and recapture its fixture in the same PR as the function fix. Preferred when the rule fix and pinning land together — each additional regression branch adds a full validation run to the regression runner (currently around 5:30 wall time).
• Add dedicated micro broken-spec branches per rule. Useful if the function fix and rule pinning land separately, or if either rule's trigger semantics need to evolve independently.

Trigger patterns are straightforward: reserved path segments for S-012, uppercase MSISDN / IMSI / phoneNumber in path or query parameter names for S-017.

Related: ReleaseManagement#483 (validation-framework Phase 3 regression coverage)