A lost header name has no confirmation path: a later re-tag of that channel is refused for good #281

Found in the review of #280 (merged as 2d1ab30); already on main before that PR.

There is no way to confirm a lost header name. If a removal is saved without re-tagging, the removed folder's header names stay in the published file. Any later re-tag of that channel is then refused permanently with R_CONFIRMED_ID_CHANGED ("undo that change"), with no action that resolves it. Reproduced on 9a8a25e.

Related design limits noted in the same review (owner decision needed, see #280's review comment):

1. A switch to another saved name (e.g. "Hoechst" → "DAPI", both saved DNA names) still publishes together with a removal, because the published file keeps no header names per folder. Closing it means refusing every header-name loss that comes with a removal, or a Spec change to record names per folder.
2. Folders that never had names are over-refused when the removed folder held a channel's only names; the message ("lost a saved header name in ") is misleading there.

Expected: an explicit, recorded way to confirm a header-name change (or a clear Spec rule that refuses it with a fix the user can carry out), and no permanent dead end.