[AliZakaee]

Summary

• invalidate a pending approval when its source customer message is edited
• keep the invalidation active even when owner monitoring notifications are disabled
• notify the owner when an edit cancels a stale proposal
• cover customer edits, monitoring-off behavior, and owner edits with regression tests

Why this is meaningful

Before this change, an approval card remained sendable after the customer changed the underlying message. The owner could therefore approve and deliver a response generated for stale text. The edit handler now reuses the same pending-only atomic invalidation path as the deletion handler, while leaving owner edits and already-handled deliveries untouched.

Validation

• Baseline: .venv/bin/python -m pytest — 279 passed
• Baseline CI-equivalent suite: .venv/bin/python -m pytest --cov=. --cov-report=term-missing --cov-report=xml --cov-report=html --junitxml=junit.xml — 279 passed, 60% total coverage
• Targeted: .venv/bin/python -m pytest tests/unit/handlers/test_business_updates.py -q — 21 passed
• Post-change CI-equivalent suite: .venv/bin/python -m pytest --cov=. --cov-report=term-missing --cov-report=xml --cov-report=html --junitxml=junit.xml — 282 passed, 61% total coverage
• .venv/bin/python -m compileall -q handlers tests — passed
• git diff --check — passed
• scoped secret and forbidden-path diff scan — passed

Risk and rollback

Risk is low: the change only transitions matching pending approvals to the existing invalidated state. It does not change the database schema, public API, configuration, dependencies, authentication, permissions, or delivery logic. A narrow concurrency case where an edit arrives before approval creation remains outside this patch. Roll back by reverting commit 05cd471.

Prepared with automated assistance by EQ for AliZakaee.