Auto-grant project-creation permission to newly registered users

[johardi]

Summary

• Self-registered users never received the ProjectCreator client role, so they never saw the "Create New Project" button — the role has only ever existed as a hand-added, ad hoc grant on running instances, and was missing from the checked-in realm export entirely.
• Defines ProjectCreator on the webprotege client and includes it in the default-roles-webprotege composite, so every new user (self-registered or admin-created) gets it automatically via Keycloak's own default-role mechanism, both on fresh installs and on already-running realms (via a new idempotent entrypoint.sh patch, following the existing fix_username_mapper pattern).
• Scope is deliberately limited to new registrations going forward — already-registered accounts are not backfilled, matching how this has been handled ad hoc until now. Also accepted as a documented residual risk: the two built-in service accounts (admin-cli, user-management) incidentally inherit the same entitlement via default-roles-webprotege, though neither currently calls WebProtege's own project-creation API.

Test plan

• ./test-entrypoint.sh passes (30/30 assertions), including a new phase that deliberately deletes the role/association and restarts to exercise the actual create/associate code path, not just the idempotent skip branches
• Verified against a real, already-installed local WebProtege stack (existing keycloak-h2-directory volume, not a fresh install): entrypoint correctly detected the pre-existing hand-added role, skipped recreating it, and added the missing composite association
• Registered a brand-new user through the live sign-up form post-fix and confirmed their effective client roles include ProjectCreator with no manual grant