feat: add @env-var tag to env-var config scenarios

[aepfli]

Summary

Adds the @env-var tag to all config scenarios that mutate system environment variables via Given an environment variable ... with value ....

Motivation

SDKs that run Cucumber scenarios in parallel need a way to serialise scenarios that mutate global process state (environment variables). Cucumber's exclusive resource mechanism can lock on a tag, but only if the feature files actually carry that tag.

Without @env-var, parallel runners either:

• disable parallelism for the entire config suite (wasteful), or
• suffer from flaky env-var races (e.g. FLAGD_PORT=3456 leaking into a scenario expecting 8015).

Tagged scenarios

Scenario	Tags added
Dedicated Config via Env_var	@env-var
Dedicated Config via Env_var special In-process case	@env-var (appended to existing)
Dedicated Config via Env_var special file case	@env-var (appended to existing)
Dedicated Config via Env_var and set	@env-var
FLAGD_SYNC_PORT takes priority over FLAGD_PORT	@env-var (appended to existing)

Companion to: open-feature/java-sdk-contrib#1752

[gemini-code-assist]

Code Review

This pull request updates the gherkin/config.feature file by adding the @env-var tag to several scenarios that manipulate environment variables. This is likely intended to facilitate resource locking or isolation during test execution. A review comment suggests extending this tag to scenarios that read default environment values to prevent potential race conditions and state leakage when tests are run concurrently.

[aepfli]

Thanks for the review!

The @env-var tag intentionally only marks writer scenarios (those that mutate env vars). The tag exists so SDK implementations can use Cucumber's exclusive resource locking to serialise them when running scenarios in parallel.

In the Java SDK (the companion PR), we handle the config suite differently: ConfigCucumberTest disables parallel execution entirely (cucumber.execution.parallel.enabled=false), so all config scenarios — both readers and writers — already run sequentially. The env-var race described here cannot occur.

Tagging reader-only scenarios like "Default Config" with @env-var would be semantically misleading — they don't touch env vars — and would unnecessarily constrain other SDKs that might want finer-grained locking (e.g. read-write for writers vs read for readers in the future).