The check miner proposes no duplicate key for a record without a key field, so clinical-write refuses every taught save on that app #1864

Found while proving MCP teach on a native macOS app (#1862). The app's rows are (id, patient_id, note). The effect miner sets idempotency_key only from a key field (DEFAULT_IDEMPOTENCY_KEY_FIELD). With no such field, the mined record_written effect carries no duplicate key, and clinical-write refuses the bundle (require_idempotency_key_for). A hand-built bundle with composite_key: {patient_id, note} certifies (benchmark/repair_every_backend/qualify_macos.py), so the policy itself accepts a composite key.

Both workarounds in the read query fail closed, as they should:

• A derived key patient_id || ':' || note is frozen to run 1's literal, so the canary is refuted.
• note AS key puts the typed value in two fields, so it is no longer lifted as a parameter.

This is not specific to any backend; it shows up wherever a system of record has no key column, which is common in desktop apps.

Close: when the read set has no key field, propose a composite_key built from the match's parameter-bound fields plus the record identity (record_fields). Show it in the proposed check that teach_confirm_checks asks a person to confirm, never apply it silently. Then rerun tests/e2e/test_mcp_teach_desktop_e2e.py under clinical-write instead of permissive.