AXIAM PHP SDK

1. String-param style — ->middleware('axiam.access:read,documents,id'), i.e. axiam.access:<action>,<scope?>,<resourceParam?>. <action> is required; <scope> defaults to null (pass '' — an empty CSV segment — to explicitly skip it while still supplying a <resourceParam>); <resourceParam> defaults to 'id', matching this SDK's own /documents/{id}-shaped example routes, so the common case only needs axiam.access:read or axiam.access:read,documents. This style never inspects controller attributes — the string params ARE the declaration for that route.
2. Attribute style — no middleware params at all (->middleware('axiam.access')), in which case this middleware reflects the CURRENT ROUTE's resolved controller (via $request->route()) for #[RequireAuth]/#[RequireRole]/#[RequireAccess] (method-level attributes take precedence over class-level ones), mirroring exactly how AxiamAccessAttributeListener reflects the Symfony controller callable — so a consuming application can annotate a controller method once and reuse it from either framework's bridge.

Deliberately type-hinted against Symfony\Component\HttpFoundation\Request (not Illuminate\Http\Request), same rationale as AxiamMiddleware's own doc comment: a real Illuminate\Http\Request IS a Symfony\Component\HttpFoundation\Request, and Laravel's kernel always passes the real subclass to route middleware, so this avoids a new illuminate/http dev/runtime dependency. The one wrinkle this class alone has to work around: route() (and the returned route's getActionName()/parameters()) exist only on Illuminate\Http\Request/Illuminate\Routing\Route, not on the Symfony parent type this class declares — self::currentRoute() reads them via a method_exists() guard followed by a variable-method-name call (not a literal $request->route() call), so neither PHPStan (which only knows the declared Symfony type) nor this class's own autoloading ever needs Illuminate\Http\Request/Illuminate\Routing\Route to exist as concrete, referenceable classes — the attribute-reflection style degrades to a silent no-op on any Request implementation that lacks a route() method (including a plain Symfony Request used directly, e.g. in tests).