bug(databricks): reliability and devx improvements

After trying the Databricks Zerobus insertion, I found a few friction points:

- setting the global config `destination.databricks.insert_api = "zerobus"` ([see docs](https://dlthub.com/docs/devel/dlt-ecosystem/destinations/databricks#enable-zerobus)) doesn't seem to work. It leaves load packages under `load/normalized/LOAD_ID/started_jobs` and fails silently. The Python process will exit cleanly, but `pipeline.run()` will not return a `LoadInfo`. We probably have a `try/except` that catches too many things
- After entering this "failure state", you're stuck because subsequent `pipeline.run()` produce this message
```shell
2026-05-14 13:33:32,508|[WARNING]|3367|248461899642048|workspace|pipeline.py|run:743|The pipeline `run` method will now load the pending load packages. The data you passed to the run function will not be extracted. In order to do that you must run the pipeline again
```
- all tables are created on Databricks, only internal tables `_dlt_pipeline_state` and `_dlt_version` receive data (because they use COPY INTO). `_dlt_loads` remain empty because the LoadJob doesn't complete
- it seems to not be producing a `Trace` object on disk either. `pipeline.last_trace` returns `None`
- OTOH, using the `databricks_adapter()` to set `insert_api="zerobus"` per resource works.
- When running the pipeline, I get a `core` file in my `cwd` that is a 1.4Gb binary without extension. I don't know if it's produced by zerobus SDK or `dlt`
- Zerobus fails "late" if your Zerobus credentials are misconfigured or if you're missing the Python SDK dependency. This is because those are only resolved when using the Zerobus `LoadJob` which conditionally happens late in the lifecycle. Ideally, we catch this at configuration resolution