Resolve the WSSE middleware from the branch that is being developed

The self-test required it at @dev, which resolves to the default branch. That
branch is 212 commits behind v4.x, where the work this harness exercises
actually lands, so the suite failed on classes that exist but not there.

v4.x is where the engine modernization merged and where the attachment work
is headed, so tracking it is what makes this workflow mean something. It goes
fully green once the attachment PR lands there; until then the attachment
cases fail for want of the classes, and the rest passes.

Author: veewee

.github/workflows/ci.yml

@@ -1,8 +1,9 @@
 name: ci
 
-# The harness's own self-test, on PHP 8.4 and 8.5. The committed composer.json declares no
-# repositories and requires the middlewares at @dev, so this resolves them from Packagist. It turns
-# green once the middleware changes the harness exercises are released to their main branches.
+# The harness's own self-test, on PHP 8.4 and 8.5. The committed composer.json declares no repositories, so
+# this resolves the middlewares from Packagist: the WSSE one from its active development branch, v4.x, rather
+# than from the stale default branch. It turns green once the middleware changes the harness exercises have
+# landed there.
 on:
   push:
   pull_request:

composer.json

@@ -12,7 +12,7 @@
         "php": "~8.4.0 || ~8.5.0",
         "ext-dom": "*",
         "ext-openssl": "*",
-        "php-soap/psr18-wsse-middleware": "@dev",
+        "php-soap/psr18-wsse-middleware": "dev-v4.x",
         "php-soap/psr18-attachments-middleware": "@dev",
         "nyholm/psr7": "^1.8",
         "symfony/http-client": "^7.1"