🐛 fix(bdd): shouldEnableV2 wrongly matched ~@v2 as @v2 substring

Pre-existing latent bug surfaced by the new @v2-gate scenario in
greet.feature (added in PR #56 follow-up): shouldEnableV2 used
strings.Contains(tags, "@v2") which matched the negation tag `~@v2`
as a positive inclusion. Result: the greet "v1" sub-test, intended
to run with v2_enabled=false, was actually starting the test server
with v2_enabled=true. The @v2-gate scenario asserting "v2 disabled →
404" got 200 instead.

Fix: parse the GODOG_TAGS expression by splitting on `&&` / `||` /
whitespace, then check each clause for exact `@v2` match (positive
inclusion only). The negation `~@v2` no longer matches.

The new BDD scenario is the regression test — without the fix, it
fails with status 200 instead of 404. With the fix, both greet "v1"
(v2 disabled) and "v2" (v2 enabled) sub-tests pass cleanly.

Verifier verdict: APPROVE. Race-clean. Full BDD suite green.

features/greet/greet.feature

@@ -15,6 +15,16 @@ Feature: Greet Service
     When I request a greeting for "John"
     Then the response should be "{\"message\":\"Hello John!\"}"
 
+  @critical @v2-gate
+  Scenario: v2 endpoint returns 404 when api.v2_enabled is disabled
+    # In the default tag-filter run (~@v2), the test server starts with
+    # v2_enabled=false. The v2EnabledGate middleware (ADR-0023 Phase 4)
+    # returns 404 with a JSON body explaining the flag state.
+    Given the server is running
+    When I send a POST request to v2 greet with name "John"
+    Then the status code should be 404
+    And the response should contain "v2 API is currently disabled"
+
   @v2 @api
   Scenario: v2 greeting with JSON POST request
     Given the server is running with v2 enabled