Feature file templates: fix the remaining gplint findings (placeholder syntax, scenario names)

[hdamker]

Problem description

After #678, gplint over artifacts/testing/*.feature reports 16 warnings: 10× no-dupe-scenario-names and 6× no-unused-variables. #676 plans to document them as expected; all three groups below are better fixed, and none requires a semantic change.

1. sample-service-template.feature mixes two placeholder conventions (6× no-unused-variables)

The tags and the error scenarios use {createResource} / {operationId}; three happy-path Scenario Outlines use <createResource> / <Resource>. Angle brackets are Gherkin's Scenario Outline variable syntax, so gplint reports them as variables absent from the Examples table — and a Gherkin runner would try to substitute them from it. Visible inside one file: line 50 When the request "<createResource>" is sent against line 199 When the request "{operationId}" is sent. The same hazard sits on <ResourceId>, <listResources>, <getResource>, <deleteResource>, <operationId>, <requestProperty>, <requestSchema> and <scope>, unflagged only because those scenarios have no Examples table.

2. event-subscription-template.feature reuses scenario names across additive scenarios (5× no-dupe-scenario-names)

Scenarios 12 to 14 (lines 150, 168, 181) carry scenario 01's name "Create <xxx> subscription (sync creation)", and scenarios 15 and 16 (lines 199, 212) carry scenario 06's "Get a subscription based on existing subscription-id.". These are additive, not alternatives: a subscription API keeps all of them, so the duplicate names propagate into every *-subscriptions.feature copied from the template. The tags already carry the distinction, and downstream APIs already name these scenarios apart (QualityOnDemand, CustomerInsights).

3. sample-service-template.feature reuses one canonical scenario name (5× no-dupe-scenario-names)

Lines 67, 90, 112, 136 and 149 repeat line 44's "Common validations for any success scenario" in two different situations: lines 44/67/90 are three mutually exclusive variants of the same scenario (device-identified API / phoneNumber-identified API / neither), of which an API author keeps one; lines 112/136/149 apply the name to different operations.

Expected behavior

1. Normalise every template placeholder in sample-service-template.feature to the {…} convention, keeping only the genuine Examples variables <property>, <condition> and <required_property>.
2. Give scenarios 12 to 16 in event-subscription-template.feature names that carry the distinction their tags already make.
3. Add a distinguishing suffix to the duplicated names in sample-service-template.feature — the variant condition for lines 44/67/90, the operation for lines 112/136/149.

No scenario, step, examples table or tag is added or removed. With all three applied, gplint --config .gplintrc artifacts/testing/*.feature reports 0 problems and #676 no longer needs a gplint section.

Alternative solution

Document all 16 as expected, the current plan in #676. Rejected: group 1 is a defect that every API repository inherits when it copies the template, and group 2 puts duplicate scenario names into every subscription API's test report.

Additional context

Best done on top of #678, which rewrites all 550 lines of event-subscription-template.feature for line endings — a change developed from main instead will conflict there.

"Common validations for any success scenario" appears in 39 feature files across the API repositories. The suffixes in group 3 extend that name rather than replace it, so the convention stays recognisable.