[cli] Fail gracefully on unsupported type annotations in config constructors

Nobody has claimed this yet.

### Description & Motivation

- When LightningCLI parses YAML configs it inspects constructor annotations via `LightningArgumentParser`/`jsonargparse`. Typing constructs such as `typing.List[str]` or `Protocol` instances (e.g., our `ModelConverter`) are not concrete runtime types, so LightningCLI raises validation/type errors before callbacks are instantiated (docs describe type-driven config parsing).
- In our repo we had to strip the annotations entirely just to unblock training:

```
trainer:

...

callbacks:
- class_path: crosslayer_transcoder.utils.callbacks.ModelConversionCallback
init_args:
converter:
class_path: crosslayer_transcoder.utils.model_converters.circuit_tracer.CircuitTracerConverter # implements ModelConverter Protocol
init_args:

...

on_events: ["on_train_batch_end"]
```

```
class ModelConversionCallback(L.Callback):

# Note: you can't type these directly with List or ModelConverter
def __init__(
self,
converter, # type: ModelConverter
on_events=["on_train_batch_end"], # type: List[str]
):
super().__init__()

...
```

### Pitch

- During schema generation, detect when an annotation is a `typing` object or protocol that `jsonargparse` can’t coerce.
- Instead of raising, fall back to treating the argument as `Any` (or defaulting to primitive validators) and log a warning pointing users to supported types.

### Alternatives

_No response_

### Additional context

_No response_

cc @lantiga @mauvilsa

Start at LightningArgumentParser and jsonargparse schema generation, reproducing the issue with typing.List[str] and the ModelConverter Protocol annotation shown in the report. Confirm that unsupported annotations no longer block callback instantiation, that a warning points to supported types, and that normal type-driven config parsing remains unchanged.

Written by the indexing model from the issue text.