Feat: Role-based scope gating for github-issue demo

[omerboehm]

Adds per-user access differentiation to the github-issue demo by moving
scope gating from the AuthProxy into Keycloak, using realm roles, client
roles, and a declarative policy mapping.

• New authbridge/demos/github-issue/config.yaml — declares clients,
  client roles, realm roles (regular, privileged), audience targets,
  and demo users (alice → regular, bob → privileged).
• New authbridge/demos/github-issue/policy.yaml — maps realm roles to
  the client roles each user is allowed to assume.
• authbridge/demos/github-issue/setup_keycloak.py — rewritten to drive
  Keycloak setup from the two config files above, creating realm roles,
  client roles, role mappings, and client-scope/role bindings so scopes
  are only issued to users whose roles authorize them.
• authbridge/demos/github-issue/k8s/configmaps.yaml — reduces
  token_scopes from "openid github-tool-aud github-full-access" to
  "openid". Keycloak now decides which scopes land in the exchanged
  token based on the requesting user's roles.
• authbridge/demos/github-issue/demo-manual.md — updated walkthrough
  to reflect the new ordering and the role/scope model.

Net effect: with the same proxy configuration, alice receives a token
limited to github-tool-aud while bob additionally receives
github-full-access — without any change to the go-processor.

Related issue(s)

This is an alternative approach to the problem described in #139
(closed as not-planned). Instead of implementing SCOPE_FORWARDING in
the go-processor, scope decisions are centralized in the IdP via
Keycloak roles and client-scope bindings. See the discussion on the
issue for the trade-off between the two approaches.

Fixes #139

(Optional) Testing Instructions

1. Follow authbridge/demos/github-issue/demo-manual.md from a clean
   cluster through Step 7 (Configure Keycloak), running:

   python authbridge/demos/github-issue/setup_keycloak.py

[huang195]

@omerboehm thanks for working on this. This is something we need, not only just for the github-issue demo but as a general security layer. We have a call next week, and we can discuss this then.

[davidhadas]

relates to rossoctl/rossoctl#931

[davidhadas]

@omerboehm, @huang195
Is this ready for merge? If so, can we merge it? If not, can anyone summarize here the status and gaps?

[omerboehm]

It’s not ready for merge yet , I am working on it

[omerboehm]

replaced with #619