Implement self registration and keycloak integration

## Feature Request

### Description of Problem:

The public sandbox at demo.fluxnova.finos.org is fully unauthenticated. Everyone shares one anonymous context: visitors cannot register their own account, there is no separation between what a demo user and an administrator can see or do, no activity can be attributed to a user (who deployed a definition, who started an instance), and the REST API is open to the internet.

When a prospective user visits the demo site, I want to sign up for my own account and explore the platform as a real, permission-scoped user, so I can evaluate Fluxnova's actual capabilities — including its identity, authorization, and audit features — instead of an anonymous shared sandbox.

When operating the demo site, we want every session and API action tied to a registered identity, so we can scope permissions, attribute activity, and reduce abuse of the public deployment.

### Potential Solutions:
Deploy Keycloak on the existing EKS cluster (`auth.fluxnova.finos.org`) as the identity provider, with self-registration (email/password with verification, plus GitHub/Google social login via identity brokering) and OIDC SSO across both UIs. This requires **no code changes** — only configuration in fluxnova-deploy:

- **Engine**: switch the chart to the official `finos/fluxnova-bpm-platform` Run image, which bundles the OAuth2/OIDC security module (`--oauth2`), and enable it via environment variables. Self-registered users land in a default group with seeded, limited authorizations; an admin group maps to full admin via Run's built-in `admin-auth` property.
- **Control Center**: enable its native OIDC support (`FXN_AUTH_STRATEGY=oidc`) against the same realm — one registration, shared SSO session.
- **Ingress**: route the engine's OIDC endpoints (`/oauth2`, `/login/oauth2`, `/logout`); `/engine-rest` initially stays open (the site's current posture), which keeps Modeler-based deployment working from day one.
- **Follow-up, gated on the upstream engine-rest JWT patch**: validate Keycloak JWTs on `/engine-rest`, closing the open API with per-user tokens (Modeler already supports bearer auth; the Control Center already forwards the user's token per request).

Validated end-to-end in a fully containerized local POC using the same images and topology (Keycloak realm export, engine config, ingress rules, seed script, branded login theme) — available as a reference implementation.

**Drawbacks/considerations**: SMTP credentials needed for email verification; FINOS-owned OAuth apps needed for social login; a public signup surface requires anti-abuse measures (brute-force protection, rate limiting, optional reCAPTCHA, periodic reset); a known one-line logout bug in the platform's SSO logout handler (upstream fix identified).

**Alternatives considered**: wiring the existing htpasswd basic-auth secret (single shared credential — no self-service, no identity, weaker UX); adding security starters to the fluxnova-examples image (rejected — complicates an onboarding-focused repo); Control Center service-account API auth (rejected in favor of forwarding the logged-in user's token — preserves per-user authorization and audit attribution).

Start by inspecting the existing fluxnova-deploy chart and EKS deployment, then compare them with the referenced containerized Keycloak POC. Configure Keycloak, the engine, Control Center, and ingress for shared OIDC registration and SSO, while preserving the stated engine-rest follow-up boundary. Done means users can self-register, sign in to both UIs, receive scoped permissions, and have activity attributed to their identity.

Written by the indexing model from the issue text.