Describe the issue

After destroying a Databricks Asset Bundle that creates a postgres_project resource, attempting to redeploy the same bundle fails with failed to create postgres_project because the project slug still exists in the workspace, even though the bundle destroy completed successfully.

Configuration

resources:
  postgres_projects:
    lakebase_project:
      project_id: ${var.project_id}
      spec:
        pg_version: ${var.pg_version}
        display_name: ${var.display_name}
        default_endpoint_settings:
          autoscaling_limit_min_cu: ${var.min_cu}
          autoscaling_limit_max_cu: ${var.max_cu}
          suspend_timeout_duration: ${var.suspend_timeout}
      permissions:
        - service_principal_name: ${var.admin_sp_app_id}
          level: CAN_MANAGE

Steps to reproduce the behavior

1. Run databricks bundle deploy -t <dev-target> — bundle deploys successfully, postgres_project is created.
2. Run databricks bundle destroy -t <dev-target> — destroy completes without errors.
3. Run databricks bundle deploy -t <dev-target> again to recreate the same bundle.
4. See error.

Expected Behavior

After a successful bundle destroy, the postgres_project (and its slug) should be fully removed from the workspace, allowing a subsequent bundle deploy to recreate it with the same project_id/slug without conflict.

Actual Behavior

The deploy fails with:

project slug already exists in the workspace [TraceId: 12asdae12]

This suggests bundle destroy is not fully deleting the underlying Lakebase/Postgres project (or the slug isn't released immediately), causing the next deploy to collide with a stale resource. The issue persist for hours.

OS and CLI version

Databricks CLI v1.2.0
OS: Windows

Is this a regression?

Not tested

Debug Logs