Access denied after trying to login without a role from Keycloak

## Describe the bug
Keycloak users might not have a role associated. While the default users created by the (ocis_keycloak) deployment example have roles, new created users in keycloak might not. This is specially true if we consider user federation in keycloak, where we can import thousands of users at once.

The main problem of users not having a role is that the web app gets stuck: the user is correctly authenticated in keycloak, there is a session active in keycloak, but the web shows an access denied. Even if we click in the "log in again" button, we'll automatically reach the same state. This can be considered an infinite loop (as long as we keep clicking the button), and we can't get out of it. There is no way out other than removing the browser's cookies / cache, which is something we shouldn't rely on.

```
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"73cb6d9668ba/YltisUGvf3-000237","traceid":"24fe1d4725e78c84179217698ed7d45d","remote-addr":"10.0.2.28","method":"GET","status":200,"path":"/oidc-callback.html","duration":1.596757,"bytes":371,"time":"2025-06-26T09:44:59Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"73cb6d9668ba/YltisUGvf3-000239","traceid":"69e1317a1220134d3a3ef52c9a1df409","remote-addr":"10.0.2.28","method":"GET","status":200,"path":"/web-oidc-callback","duration":1.713372,"bytes":3244,"time":"2025-06-26T09:44:59Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"cf1a7a99-0728-4775-bbe1-fc7230682672","traceid":"39159476a62da94dece388a9f7f0bf02","remote-addr":"10.0.2.28","method":"GET","status":200,"path":"/config.json","duration":1.343893,"bytes":348,"time":"2025-06-26T09:45:00Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"cd433a70-e92a-41bb-a862-6fde10bbe01d","traceid":"1733d4aa6465eca267226ecb922f5ec8","remote-addr":"10.0.2.28","method":"GET","status":200,"path":"/themes/owncloud/theme.json","duration":1.257157,"bytes":6481,"time":"2025-06-26T09:45:00Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
{"level":"info","service":"frontend","pkg":"rhttp","traceid":"78fd59aba56f395d7343c5fbf8baf482","time":"2025-06-26T09:45:01Z","line":"github.com/cs3org/reva/v2@v2.27.7/internal/http/interceptors/auth/auth.go:195","message":"skipping auth check for: /app/list"}
{"level":"warn","service":"frontend","pkg":"rhttp","traceid":"78fd59aba56f395d7343c5fbf8baf482","time":"2025-06-26T09:45:01Z","line":"github.com/cs3org/reva/v2@v2.27.7/internal/http/interceptors/auth/auth.go:248","message":"core access token not set"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"2c18154b-c93a-41d1-a781-e2f539c9a4b7","traceid":"3ff95e25e0f9440bfbb09399088e60c8","remote-addr":"10.0.2.28","method":"GET","status":200,"path":"/app/list","duration":4.255424,"bytes":17,"time":"2025-06-26T09:45:01Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
{"level":"info","service":"auth-machine","pkg":"rgrpc","traceid":"cc78fb9b3c954ae550f638e3059caf07","time":"2025-06-26T09:45:01Z","line":"github.com/cs3org/reva/v2@v2.27.7/internal/grpc/services/authprovider/authprovider.go:146","message":"user idp:\"https://keycloak.jp.solidgear.prv/realms/oCIS\" opaque_id:\"e1bd9e18-2312-4e55-bdf0-06aeae507195\" type:USER_TYPE_PRIMARY authenticated"}
{"level":"error","service":"proxy","request-id":"45bcc541-f5c7-4961-8cbe-7b623e34fc16","userid":"e1bd9e18-2312-4e55-bdf0-06aeae507195","error":"no role in claim maps to an ocis role","time":"2025-06-26T09:45:01Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/userroles/oidcroles.go:108"}
{"level":"error","service":"proxy","error":"no role in claim maps to an ocis role","time":"2025-06-26T09:45:01Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/account_resolver.go:174","message":"Could not get user roles"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"45bcc541-f5c7-4961-8cbe-7b623e34fc16","traceid":"cc78fb9b3c954ae550f638e3059caf07","remote-addr":"10.0.2.28","method":"GET","status":500,"path":"/ocs/v1.php/cloud/capabilities","duration":79.874948,"bytes":0,"time":"2025-06-26T09:45:01Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
```

## Steps to reproduce
1. Start by using the "ocis_keycloak" deployment example
2. Create a new user in keycloak, ensure there is no ocis role associated with him
3. Try to login with the new user.

## Expected behavior
A default role should be used. It could be configurable and default to "user-light" / "guest"

## Actual behavior
The oidc claim doesn't contain a role, and the request fails with a 500 error.

## Setup
Reproducible with the "ocis_keycloak" deployment example.

```console
OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue
```

## Additional context
There are several missing pieces in the docs regarding this issue:
* Roles in keycloak aren't defined.
* Can we change the roles names in keycloak? Can we use different names, such as "external_user" instead of "ocisGuest"?
* Can we add or remove the provided roles in keycloak? What happens if we do so?
* Should we consider the roles as hardcoded so they shouldn't be touched? What if I want to create my own keycloak deployment? How much am I allowed to adjust?
* It's unclear what are the usage expectations, at least for the time being.
* While we don't want to expend too much time on how to add new users in keycloak, we're relying on specific roles. This needs to be clear. People are unlikely to change things like roles if it isn't required, and it isn't part of the user creation.
* User federation in keycloak isn't mentioned. Whether we support this case or not, or we require specific steps to successfully use those users in ocis (configuring specific mappers to assign roles to those users, for example), is something that should be in the docs.

My concern is that I think user federation is important specially for enterprise, and without any guidance the users will be loaded into keycloak without any role, leading to this ticket.
Note that, while keycloak is mentioned because we have a deployment for it, other IDPs will likely have the same issue.