LoraConfig/TorchTuneConfig accept invalid PEFT hyperparameters, and valid 0/[] values are silently dropped

### What happened?

While going through `kubeflow/trainer/types/types.py` and
`kubeflow/trainer/backends/kubernetes/utils.py`, I found two related gaps in the
TorchTune LoRA/PEFT fine-tuning path:

**1. `LoraConfig` has no validation on its hyperparameters.**

```python
from kubeflow.trainer import LoraConfig

LoraConfig(lora_rank=0) # accepted, will fail deep inside TorchTune at runtime
LoraConfig(lora_rank=-8) # accepted
LoraConfig(lora_alpha=-1) # accepted
LoraConfig(lora_dropout=1.5) # accepted, should be constrained to 0.0-1.0
```

None of these raise an error at construction time, so a typo or a bad config value
surfaces later as an opaque failure inside the TorchTune runtime instead of a clear
`ValueError` where the config was created.

**2. `batch_size=0`, `epochs=0`, and `lora_attn_modules=[]` are silently dropped.**

In `get_args_using_torchtune_config`:

```python
if fine_tuning_config.batch_size: # falsy check — batch_size=0 is silently skipped
args.append(f"batch_size={fine_tuning_config.batch_size}")

if fine_tuning_config.epochs: # same issue for epochs=0
args.append(f"epochs={fine_tuning_config.epochs}")
```

And in `get_args_from_peft_config`:

```python
if peft_config.lora_attn_modules: # an explicit empty list is silently dropped too
args.append(f"model.lora_attn_modules=[{','.join(peft_config.lora_attn_modules)}]")
```

If a user explicitly sets one of these to a falsy-but-valid value, it's dropped with
no error and no indication that anything happened.

### What did you expect to happen?

- Constructing a `LoraConfig` with an out-of-range `lora_rank`/`lora_alpha`/`lora_dropout`
should raise a `ValueError` immediately, with a clear message about which field and
why — not fail later inside TorchTune.
- Explicitly-set falsy values (`batch_size=0`, `epochs=0`, `lora_attn_modules=[]`)
should not be silently dropped from the generated trainer args.

### Environment

Kubeflow Python SDK version:
```bash
$ pip show kubeflow
Version: 0.4.1
```

Kubernetes / Kubeflow Trainer version: not applicable since this is reproducible in pure
Python, without a cluster, since it's purely in the SDK's dataclass and arg-building
logic

Start in kubeflow/trainer/types/types.py by reading LoraConfig and its hyperparameter fields, then inspect get_args_using_torchtune_config and get_args_from_peft_config in kubeflow/trainer/backends/kubernetes/utils.py. Reproduce the listed constructor and argument-building cases in pure Python. Done means invalid LoRA values fail clearly at construction and explicitly supplied falsy values are preserved in generated trainer arguments.

Written by the indexing model from the issue text.