CLI: include input.yaml config values in workflow describe output #12

Problem

taskmaestro workflow describe --input input.yaml --json (introduced in #11) validates the input file, but only reports which config fields are set:

"provided_config_fields": ["end_date", "output_dir"]

It doesn't report what they're set to. A UI (e.g. ResInsight) wants to pre-fill its editor with the values the user already has in input.yaml. Today it has to parse the YAML itself and repeat taskmaestro's per-task config lookup logic. The model defaults in input_schema don't help here, because they're the defaults, not the user's values.

Proposal

Add a config_values object to each task, next to provided_config_fields. It's null when --input isn't given, the same as provided_config_fields.

{
  "name": "export_grid",
  "config_fields": ["end_date", "grid_case", "output_dir", "scale"],
  "provided_config_fields": ["end_date", "grid_case", "output_dir"],
  "config_values": {
    "end_date": "2030-01-01",
    "grid_case": {"__resinsight_ref__": "EclipseCase", "case_id": 0},
    "output_dir": "/tmp/out"
  },
  "input_schema": { "...": "..." }
}

Semantics

• Values are exactly what's written in input.yaml for that task, after taskmaestro's per-task lookup but before Pydantic validation. That way opaque or runtime-only types (such as marker dicts) come through unchanged, and the command never has to build Python objects.
• They're converted to JSON: dates and datetimes become ISO 8601 strings, and paths become strings.
• Only fields in provided_config_fields appear in config_values. Anything else falls back to input_schema.properties.<field>.default.

Alternative I'd avoid

Putting the values into input_schema as default would mix up the model's defaults with the user's input.