Choose or clear this connection's target dataset. Owner-only (CLO-1014).

Takes effect on the next sync only — an already-dispatched or in-flight sync keeps ingesting into whatever it was handed, the same as changing the resource selection does; a sync already in flight answers 409 unconditionally instead (finding #7), not only when delete_old_target is set — a target changing under GitHub's clone directory mid-sync is unsafe regardless of whether anything is also being deleted.

payload.dataset_id is checked against :func:~.flow.list_writable_datasets, never trusted from the request body alone — that list is also where a name shaped like some connector's own default has already been excluded (finding #1), and this route stores that list's own name for the id, never payload.dataset_name (finding #2): a client-supplied name is cosmetic only, until it is replaced with the one the pod itself reports for that id.

Write, then delete, never the other way round (finding #6). The new target is recorded first, under the row's own lock, with an optimistic check that nobody moved the target from under this request between the read above and the write; only once that has committed does a requested delete_old_target run. A delete that then fails leaves the connection pointed at its new target with the old one's content merely undeleted — recorded in previous_targets for a later retry — rather than the reverse order's failure mode, where a successful delete followed by a failed write would leave the connection believing it still owns content that is already gone.