Fix diagram; fix text

docs/user/05-60-kyma-bindings.md

@@ -43,7 +43,7 @@ The first check verifies the expiration value. The minimum and maximum limits ar
 Next, KEB checks the status of the instance. The instance must be provisioned for the binding creation. 
 After checking the instance, KEB checks if the binding already exists. The binding in the database is identified by the Kyma instance ID and the binding ID, which are passed as a path query parameter. If the binding exists, KEB checks the mutation of the parameters of the existing binding. 
 The OSB API requires a request to create a binding to fail if an object has already been created and the request contains different parameters. 
-If the found binding is not expired, KEB returns it in the response. If the found binding is expired and exists in the database, KEB responds with an error and Bad Request status.
+If the found binding is not expired, KEB returns it in the response. If the found binding is expired and exists in the database, KEB responds with an error and the Bad Request status.
 This check is done in an implicit database insert statement. The query fails for expired but existing bindings because the primary key is defined on the instance and binding IDs, not the expiration date. This is the case until the cleanup job removes the expired binding from the database. 
 If the binding does not exist, the flow returns to the process's execution path, where no bindings exist in the database. 
 Whether the binding exists or not, the last step in the request validation is to verify the number of bindings. 
@@ -56,7 +56,7 @@ If the limit is not exceeded and the binding does not exist in the database, KEB
 In the binding creation phase, KEB creates a service binding object and generates a kubeconfig file with a JWT token. The kubeconfig file is valid for a specified period, defaulted or set in the request body. 
 
 > [!NOTE]
->  Expired bindings do not count towards the bindings limit. However, they prevent creating new bindings with the same ID until they exist in the database. Only after they are removed by the cleanup job or manually can the binding be recreated again.
+>  Expired bindings do not count towards the bindings limit. However, as long as they exist in the database, they prevent creating new bindings with the same ID. Only after they are removed by the cleanup job or manually can the binding be recreated again.
 
 After the insert has been done, KEB creates ServiceAccount, ClusterRole (administrator privileges), and ClusterRoleBinding, all named `kyma-binding-{{binding_id}}`. You can use the ClusterRole to modify permissions granted to the kubeconfig.