Configurable RBAC: define roles and permissions via config

[bburda]

Summary

The role-to-endpoint permission mapping is currently hardcoded. AuthManager::check_authorization()
only consults AuthConfig::get_role_permissions(), which is a compiled method:path map
(~600 lines in auth_config.cpp). Deployers cannot change which role an endpoint requires,
add permissions, or define their own roles without recompiling the gateway.

YAML config today only controls require_auth_for (none/write/all) and the client list
(client:secret:role). The four roles (viewer, operator, configurator, admin) and their
permissions are fixed.

Proposed solution

The matching engine already exists, only the source of permissions is hardcoded:

• check_authorization() already does exact method:path match plus wildcard patterns
  via matches_path(). Feed it permissions loaded from config, layered over (or replacing)
  the built-in defaults.
• JwtClaims.permissions ("explicit permissions") is already issued into and decoded from
  the JWT, but check_authorization() never reads it. Wire it in so per-client explicit
  permissions are honored.
• Keep the current built-in mapping as the default when no config is provided, so existing
  deployments do not change behavior.

Open design point: UserRole is an enum (viewer/operator/configurator/admin). Custom
permissions for the existing roles is small. Defining new role names needs moving from the
enum to string-based roles / a role registry. We can ship custom-permissions first and decide
on custom-roles separately.

Additional context

Relates to #259 (security hardening). New write endpoints currently need their role
assignment baked into the compiled defaults; this issue removes that limitation.