Why
When a Drafts delete cannot be safely admitted, the row is restored but the user receives no visible explanation. The existing fail-closed behavior correctly preserves content; a brief notice would make the outcome understandable.
This is the remaining user-feedback enhancement split from #133 after the functional fixes in #137, #138, and #143.
Scope
- Show a brief, non-blocking notice when a user-initiated Drafts deletion is refused.
- Cover single-row and thread deletion where applicable, without duplicate notices for one gesture.
- Reuse the existing notification/toast presentation mechanism and keep wording understandable without exposing technical identifiers.
- Preserve the current refusal, row-restoration, ownership checks, and deletion pipeline. Do not add retries, recovery machinery, or changes to Archive/Move policy.
Acceptance
A refused deletion leaves the draft available and visibly explains that it was not deleted. Successful deletion produces no refusal notice. Keep tests focused on notice behavior and existing state preservation.
Legacy stranded-draft cleanup remains #136; deferred lifecycle coverage remains #145.
Why
When a Drafts delete cannot be safely admitted, the row is restored but the user receives no visible explanation. The existing fail-closed behavior correctly preserves content; a brief notice would make the outcome understandable.
This is the remaining user-feedback enhancement split from #133 after the functional fixes in #137, #138, and #143.
Scope
Acceptance
A refused deletion leaves the draft available and visibly explains that it was not deleted. Successful deletion produces no refusal notice. Keep tests focused on notice behavior and existing state preservation.
Legacy stranded-draft cleanup remains #136; deferred lifecycle coverage remains #145.