docs(ske): warn that load balancers block cluster deletion

[FabianHardt]

Documentation and error message only — no behaviour change. Companion to #1646.

Problem

A Service of type LoadBalancer makes the cloud controller create a load
balancer in the project. It belongs to no Terraform state, so terraform destroy removes the cluster and nobody removes the load balancer. The shoot
waits for it, and the cluster stays in STATE_DELETING until
DeleteClusterWaitHandler gives up after 90 minutes.

Nothing points at the cause. STATE_DELETING is indistinguishable from "slow",
and the error after the timeout is:

Error deleting cluster: Cluster deletion waiting: ...

In our case that cost about an hour before we found the load balancer still in
STATUS_READY next to a cluster that would not go away.

Change

1. A note on the stackit_ske_cluster resource description, rendered as a
   warning callout:

   Before destroying a cluster, remove any Service of type LoadBalancer
   from it. Such a service makes the cloud controller create a load balancer
   in the project, which belongs to no Terraform state. If it still exists,
   the cluster stays in STATE_DELETING until this resource times out after
   90 minutes.

2. The timeout error now names the likely cause and the command to check:

   Cluster deletion waiting: <err>.
   
   A cluster can stay in STATE_DELETING because of resources it created outside
   of Terraform. The most common one is a load balancer: a Service of type
   LoadBalancer makes the cloud controller create one in the project, and it is
   not removed by deleting the cluster. Check with
   `stackit load-balancer list -p <project>` and remove any leftovers, then retry.
   

docs/resources/ske_cluster.md was regenerated with scripts/tfplugindocs.sh;
only that file changed.

Deliberately not doing

Deleting the load balancers from the provider. stackit_ske_cluster never
created them, and working out which ones belong to a given cluster would mean
deleting resources the provider does not manage — in a project with a second
cluster or a manually created load balancer that would be actively harmful.

The real fix belongs on the service side and is filed as #1646: either the
shoot cleans up what it caused, or the cluster status says what it is waiting
for. This PR only shortens the road to that knowledge in the meantime.

Checks

gofmt -l / go vet                      -> clean
go test ./stackit/internal/services/ske/...  -> ok
scripts/tfplugindocs.sh                -> only ske_cluster.md changed