Unbind Project

Detach a project from its workspace.

The client half of this is altimate-code's unlink: without a server-side delete, dropping the local cache row achieves nothing, because the CLI re-asks the server for a binding whenever its cache misses and would silently re-link the project on the next resolve.

Soft delete, matching _soft_delete_bindings_for_datamate: the partial unique index is on the identifier WHERE is_deleted IS FALSE, so clearing the flag is what frees the remote or path to be bound again. A hard delete would also work for the index but would discard when the project was first linked, which is the one thing an audit of a re-link wants.

Identifiers work as they do on the bind path — at least one of repo_remote or project_path, and the pair is resolved independently because a remote is tenant-global while a path is per-user. If both are supplied and they name different bindings, that is 409 rather than a guess: deleting the wrong one is not recoverable from the client, which cannot see the row it did not mean to touch.

Authorization is the binder, not the workspace owner — the same rule rebind_by_remote applies, and for the same reason. Owning the workspace a project happens to be bound to should not let you detach someone else's checkout. A binding the caller did not create answers 404 rather than 403, so this endpoint cannot be used to probe which remotes are bound in the tenant.

Not idempotent by design: a second call answers 404. The alternative — 204 for "already gone" — reads the same as success to a client that is retrying blind, and unlink is a state change a user asked for and should be told the truth about. Callers that genuinely do not care can treat 404 as terminal.