Reconcile legacy drafts stranded by historical Archive and Undo flows

[tabmail-kmyi]

Summary

Before Drafts-source Archive and Move are prohibited, a draft could be moved out of Drafts and later returned without a usable provider-native address. Its local authored Draft row may survive after the visible server/header state changes, potentially reopening old content on a later Reply.

Why this is separate

The #133 prevention fix removes the producer of new Archive/Undo-stranded drafts. Repairing already-existing rows requires an explicit ownership and recovery policy and should not add reconciliation machinery to the prevention PR.

Investigation requirements

• Census the exact legacy states that shipped code could produce.
• Distinguish a locally authored draft with unsynced bytes from a safely removable orphan.
• Prove provider identity and generation before deleting or adopting local authored state.
• Prefer existing foreground/full-sync recovery where sufficient.
• Do not select a wire mutation target by RFC 822 Message-ID.

Scope exclusions

No change to the prevention guard, no generalized draft-delete redesign, and no migration until the reachable legacy population and required authority are proven.

Relationship

Follow-up to #133. Lower priority because the prevention fix stops new instances; this issue concerns historical residue only.