auth.m2m: Support configurable route path suffixes for OAuth2 endpoints

[intel352]

Problem

The auth.m2m module's Handle() method routes requests using strings.HasSuffix() with hardcoded suffixes:

case r.Method == http.MethodPost && strings.HasSuffix(path, "/oauth/token"):
case r.Method == http.MethodPost && strings.HasSuffix(path, "/oauth/revoke"):
case r.Method == http.MethodPost && strings.HasSuffix(path, "/oauth/introspect"):
case r.Method == http.MethodGet && strings.HasSuffix(path, "/oauth/jwks"):

This creates a mismatch when integrating with systems that expect different OAuth endpoint paths. For example, RFC 7662 § 2 defines the introspection endpoint as a standalone path, but many real-world OAuth servers (ORY Fosite, Auth0, Okta) expose it as a sub-path of the token endpoint:

• auth.m2m expects: POST /oauth/introspect
• Many implementations expect: POST /oauth/token/introspect

Similarly for revocation:

• auth.m2m expects: POST /oauth/revoke
• Many implementations expect: POST /oauth/token/revoke

Current Workaround

Consumers must add custom Go code to intercept requests at the legacy paths, rewrite r.URL.Path, and delegate to the M2MAuthModule.Handle() method. This requires:

1. Finding the M2MAuthModule instance in the service registry
2. Finding the StandardHTTPRouter to register additional routes
3. Implementing a path-rewriting wrapper

This is boilerplate that every consumer migrating from a Fosite/Auth0-style OAuth server needs.

Proposed Solution

Add a configuration option to auth.m2m that allows customizing the endpoint path suffixes, or support path aliases:

Option A: Configurable suffixes

- name: m2m-auth
  type: auth.m2m
  config:
    endpoints:
      token: /oauth/token
      introspect: /oauth/token/introspect  # custom path
      revoke: /oauth/token/revoke           # custom path
      jwks: /oauth/jwks

Option B: Path aliases

- name: m2m-auth
  type: auth.m2m
  config:
    path_aliases:
      introspect: ["/oauth/introspect", "/oauth/token/introspect"]
      revoke: ["/oauth/revoke", "/oauth/token/revoke"]

Option C: Support additional route registration in YAML

Allow the workflows.http.routes section to register multiple paths for the same handler, and have the Handle() method be more flexible about path matching (e.g., matching on the last path segment rather than a full suffix).

Impact

This affects any consumer migrating to the workflow engine from an existing OAuth2 server implementation that used different endpoint paths. The migration forces either:

• Custom Go code for path rewriting (defeats the zero-code YAML philosophy)
• Updating all OAuth clients to use new paths (often not feasible for third-party integrations)