identity-mappings

Confirmed mappings only — the list a caller wiring up the actual notify path would read. See GET .../suggested for unconfirmed proposals.

An admin directly declares a confirmed mapping — the explicit, source-of-truth path requirement 1 in the spec asks for, independent of auto-suggest entirely. Upserts on (org_id, git_identity): re-running this for an identity that already has a row (confirmed or suggested) overwrites it with the admin's explicit choice, since a human directly setting this is a stronger signal than whatever auto-suggest proposed.

Runs the same-email auto-suggest heuristic now and returns the resulting suggested list (existing suggestions included, not just new ones — see suggest_identity_mappings' own docstring). Admin-triggered rather than a nightly sweep: nothing in the spec asks for this to run on its own schedule, and this alone is enough for an admin to populate the suggested list before confirming from it.

Turns a suggested row into a confirmed one — the one step that makes an auto-suggested match usable for a real notification (see resolve_slack_user_id's own docstring on why that gate is a hard requirement, not optional). A no-op 400 if the row is already confirmed, since there's nothing left for this action to do.

Discards a suggested row outright — rejecting a suggestion deletes it rather than leaving a "rejected" row behind, so a later refresh-suggestions run is free to propose the same or a different match for that identity again (there's no real value in remembering a rejection here the way, say, ContradictionFinding's dedup log remembers a filed issue). Only valid on a suggested row: a confirmed mapping is a real, in-use mapping — removing one of those is DELETE .../{mapping_id}, a deliberately different, more consequential action, not this one.

Removes a mapping outright, confirmed or suggested — the general "unmap this identity" action the settings surface needs alongside confirm/reject.