Bind one of a choose_installation outcome's ids to this tenant.

Idempotent: linking an id that is already this tenant's active connection just re-confirms it, through the exact same write path (:func:flow.store_installation) an ordinary reconnect of a live row already uses, so selection and resource_health survive and nothing is reset. Linking a revoked row's own installation id takes the other branch of that same function instead: fresh selection, fresh resource_health, because picking the previous org again (CLO-627) must be a clean session, not a silent resurrection of a relationship the tenant ended. Either way the dataset is the same one as before - the connector's sticky metadata (GitHub's dataset_key) carries forward regardless of status; only a genuinely different installation id gets a new one.

Same token/user/owner validation as GET /{provider}/link-choices, see that route's docstring for why failures here are ordinary HTTP errors rather than /complete's outcome-slug shape.