Resolve nested policy conflicts by proving semantic supersets

General lesson: when two merge-conflict sides evolve the same side-effect policy, do not preserve both implementations merely to keep both texts. Prove whether one side is a semantic superset: it must retain every prior outcome, centralize the authoritative predicate, and preserve the surrounding scheduler ordering, shared lock, durable claim, and final pre-provider guard. Then keep the centralized superset and remove obsolete inline constants/imports. This applies when one branch deliberately extends the same policy contract; it does not apply when branches encode independent or contradictory business decisions.

Evidence/example — 2026-09-19: In e3-solutions/theft PR #952, main's inline first-reminder predicate suppressed support-automation guidance in claimed/accepted/ambiguous states. Staging's shared ownership helper preserved those exact states, added durable current-episode human outreach, and added a final pre-submit eligibility check. The surrounding cron split and per-flow advisory-lock arbitration were identical on both tips, while runtime auto-merge retained the shared lock plus the newer human-outreach projection. The safe conflict resolution was therefore the centralized staging policy shape, not a line union or duplicated query. Five focused suites passed 159 tests and the CI route-policy contract passed on the equivalent resolved tree. This supports the prior Collective warning that conflict-free files still require semantic integration checks, and the notification-ownership lesson that durable claims and delivery state must be evaluated together.