Workflow import: restartInProgress/cancelInProgress stored as camelCase keys Keycloak never reads (silently inactive)

### Current Behavior

Importing a workflow with root-level `restartInProgress` / `cancelInProgress` (the fields that avoid the create-NPE from #1667) succeeds — but the two settings are **silently inactive**.

Cause: keycloak-config-cli's `WorkflowRepresentation` serializes these fields under their Java (camelCase) names. Keycloak's `POST /admin/realms/{realm}/workflows` stores unknown keys verbatim in the workflow component config, but the engine reads the kebab-case constants from `org.keycloak.representations.workflows.WorkflowConstants`: `restart-in-progress` / `cancel-in-progress` (see `EventBasedWorkflow#restart` / `#deactivate` calling `model.getConfig().getFirst(CONFIG_RESTART_IN_PROGRESS)`).

Stored component config after import (Keycloak 26.6.4, `component_config` table for the workflow component):

```
cancelInProgress | true
conditions | ...
enabled | true
name | ...
on | client-created
restartInProgress |
schedule.after | 40s
schedule.batch-size | 100
supports | CLIENTS
```

`restartInProgress` / `cancelInProgress` are dead keys: `GET /admin/realms/{realm}/workflows` does not echo them, and events matching the restart expression do not reset in-progress workflows.

Proof it is only the key name: renaming the two rows to `restart-in-progress` / `cancel-in-progress` directly in the database and clearing the realm cache makes restart-on-event work immediately, with no other change.

### Expected Behavior

The concurrency settings are sent under the key names the Keycloak engine actually reads (kebab-case, and/or nested per Keycloak's own workflow representation), so that `restart-in-progress` / `cancel-in-progress` semantics are active after import. Alternatively, if the target Keycloak cannot honor them, fail or warn instead of importing dead configuration.

### Steps To Reproduce

1. Keycloak 26.6.4 with the workflows feature (default-enabled), keycloak-config-cli 6.5.1.
2. Import file (note `"on"` must be quoted in YAML — unquoted `on` becomes a boolean key, which is the "unknown property 'true'" effect mentioned in #1667):

```yaml
realm: myrealm
enabled: true
workflows:
- name: test-workflow
enabled: true
"on": user-created
restartInProgress: user-authenticated
cancelInProgress: "true"
steps:
- uses: disable-user
after: 2m
```

3. Import succeeds ("Create workflow 'test-workflow'").
4. Inspect the stored config (`component_config` table, or note that `GET /admin/realms/myrealm/workflows` does not return the concurrency settings): the keys are stored as `restartInProgress` / `cancelInProgress`.
5. Trigger an event matching the restart expression for a resource with an in-progress workflow: the scheduled step timestamp does not move.
6. Rename the two config rows to `restart-in-progress` / `cancel-in-progress` (and clear the realm cache): the same event now restarts the workflow.

### Deployment Method

Docker

### Environment

- Keycloak Version: 26.6.4
- keycloak-config-cli Version: 6.5.1 (image `adorsys/keycloak-config-cli:latest-26.5.5`)
- Java Version: 21

### Relevant configuration (sanitized)

See reproduction step 2.

### Logs / error output

None — that is the problem: the import is green and the settings are silently dead.

### Anything else?

Related to #1667: the root-level fields are the community workaround for the create-NPE described there, so users who apply that workaround land directly on this issue. Same underlying cause as PR #1476's fix — the hand-rolled workflow model drifting from Keycloak's wire format, which is still moving.

Transparency note: this investigation and issue text were prepared with AI assistance; the behavior and the database-level evidence were verified by the reporter against a local Keycloak 26.6.4 + config-cli 6.5.1 deployment.