fix(crm): bind merge application to the proposal that was reviewed

[kmonsoe]

Stacked on #717, which is stacked on #716. Land order is 716, 717, 718, retargeting each child before its parent merges.

Third and last of the propose-approve binding fixes. This is the worst of the three.

Why it is worse than the other two

crm_apply_merge_proposal took only { id }, same as the others. The difference is the mutation path and the absence of any tell.

crm_propose_merge does not always create a proposal. On a pair that already has a pending one it updates that row in place (crm.service.ts:1046), overwriting confidence, evidence, recommendedKeeperId and recommendedPatch under the same id. And crm_merge_proposals has none of the review tracking outreach_proposals has: no revisionCount, no revisedAfterReviewAt, no firstViewedAt (schema.ts:1807 shows those columns are outreach-only). Outreach at least rendered "revised 2 times" on the card. Here there is nothing.

So: agent files merge(Ada, A. Lovelace) keeper Ada. Operator reads it. Agent re-files the same pair with the keeper flipped. Same id, same card, no counter. Operator clicks Apply and Ada is the one retired.

Apply is also not a small write. It copies the patch onto the keeper, repoints activities, deals and relationships on both sides, archives the duplicate with doNotContact: true and a cleared endUserId, auto-dismisses every pending outreach proposal for the duplicate, and auto-dismisses other pending merge proposals touching it. Not a hard delete, so not strictly unrecoverable, but unwinding it by hand is not realistic and the dismissed outreach followups do not come back (a dismissed followup permanently ends that sequence).

What changed

mergeFingerprint over (contactAId, contactBId, recommendedKeeperId, confidence, recommendedPatch), computed on read, no column and no migration. Required by crm_apply_merge_proposal({ id, fingerprint }) and by POST /v1/crm/merge-proposals/:id/apply. A mismatch is a 409 with crm_conflict; nothing is merged and the proposal stays pending.

The patch is canonicalised before hashing (object keys sorted recursively, array order preserved) so jsonb round-trips do not produce spurious conflicts.

The two scoping calls

Contact rows are excluded. The card renders contact names and emails, and crm_update_contact can change them. Including them would catch that, but contact rows move for ordinary reasons and a merge queue that sits overnight would start throwing conflicts on untampered work. Operators who see conflicts on legitimate work learn to click through them, which costs more than the case it catches. And the harm is asymmetric: an edited email makes the card stale, an flipped keeper retires the wrong person.

evidence is excluded. This is what makes the weekly hygiene pass compatible with a queue in progress: re-proposing a pending pair with refreshed reasoning leaves the fingerprint alone, so only a changed decision invalidates a review. There is a test for exactly this.

Tests

Backend-core green (1363). New coverage: apply refused after a re-propose flips the keeper, asserting the proposal stays pending and neither contact was archived; the fingerprint moves on a changed patch or confidence; a re-propose that only refreshes evidence keeps it stable and still applies; unit tests for patch key-order insensitivity and array-order sensitivity; the Slack apply button carries the digest; a stale Slack button is refused with crm_conflict and leaves the proposal pending.

skill://crm/clean-contact-data updated, including a new "don't re-propose a pair with a different keeper while the operator is reviewing it" entry, and fixtures regenerated.

Still open

Option 3 from the discussion: revisionCount / lastRevisedAt columns on crm_merge_proposals so the card can show what changed rather than just refusing. Needs a migration, no new RLS policy. Worth doing, deliberately not bundled here.

🤖 Generated with Claude Code