A removal or rename answer accepts any change of a channel ID it touches, including a lost header name elsewhere #279

Found in the review of #278 (merged as b6f821a); older than that PR, not part of #258.

A §4.6 re-confirmation names an ID, not a position. When the user answers a removal (Yes, remove) or a rename, the recorded re-confirmation covers the channel IDs that answer touches by ID. Publication then accepts any change of those channel IDs, including a lost header name in another, still-existing folder. That folder's change is not listed as a move, so the user never saw or confirmed it.

#278 fixed the related case for re-ordered positions (every lost position in a folder that still exists is now listed and needs its own click). The remaining gap is lost header names in still-existing folders when a removal or rename elsewhere covers the same ID.

Expected: a re-confirmation from a removal or rename covers only the change the user answered. Any other change of the same channel ID in a still-existing folder is shown and needs its own explicit confirmation, or publication refuses (R_CONFIRMED_ID_CHANGED). Regression test: save; in folder A lose a channel's header name; remove folder B that holds the same channel ID; answer Yes, remove. Publication must not accept folder A's change silently.