Support a pre-acquired bearer token for authentication

### Problem Statement

keycloak-config-cli can only authenticate by performing a grant-type login itself: it needs either user/password credentials or a client/secret (`client_credentials`), configured via `keycloak.user`/`keycloak.password` or `keycloak.client-secret`. There is no way to hand kcc a bearer token that the caller has already obtained out-of-band. In environments where the operator authenticates interactively (e.g. via the OAuth Device Authorization Grant in a browser), there is no path to feed that resulting token to kcc — you are forced to provision long-lived admin credentials or a service-account secret just so kcc can log in again.

### Proposed Solution

Add an optional `keycloak.authorization` property (env `KEYCLOAK_AUTHORIZATION`) that accepts a raw bearer token (without the `Bearer ` prefix). When set, kcc bypasses the grant-type login flow entirely and authenticates with the supplied token via the admin-client's `KeycloakBuilder.authorization(...)`.

Because there is no refresh token in this mode, token refresh and logout become no-ops; the caller owns the token lifecycle and the token must remain valid for the duration of the run.

### Use-case context

An operator runs a short interactive workflow: they log in to Keycloak in a browser (Device Authorization Grant), obtain a short-lived user access token, and pass it to kcc for a one-shot import — instead of storing long-lived admin credentials or a service-account secret in the environment.

### Alternatives considered

- **Long-lived service-account / admin credentials**: works today, but requires provisioning and storing standing secrets, which is exactly what the interactive flow tries to avoid.
- **Teaching kcc to perform the Device Authorization Grant itself**: much larger scope and couples kcc to a specific interactive flow; passing in an already-acquired token keeps kcc agnostic about how the token was obtained.

### Acceptance Criteria

- [ ] As a user, I can supply a pre-acquired bearer token via `keycloak.authorization` / `KEYCLOAK_AUTHORIZATION`.
- [ ] When set, the grant-type login flow is bypassed and the token is used directly.
- [ ] Token refresh and logout are no-ops in this mode (no refresh token available; caller owns lifecycle).
- [ ] Existing `password` and `client_credentials` flows are unchanged when the property is not set.
- [ ] The new option is documented (README + CHANGELOG).