When a tag is marked as deleted (removed) in the metadata box, the "new" column displays the old value with strikethrough to visually indicate that the tag will be removed upon saving. However, when the user copies that cell (either single-item Ctrl+C or multi-selection copy), the clipboard receives the old value as if it were the actual new value.

This leads to two issues:
  
1. Misleading copy output: The copied text/TSV suggests the tag has a value, when in reality it's being deleted. For example, if genre = "Rock" is marked for deletion, copying the new column produces "Rock" instead of an empty string.
2. Incorrect paste behavior: When the copied data is pasted (internally via the JSON mime format), the old value gets applied as if it's a new value — effectively undoing the deletion. The paste handler has no way to know the tag was supposed to be removed, since the JSON payload just contains the value without any removal indicator.
  
The root cause is that the copy logic (get_selected_tags and the single-item path in _copy_value) does not check the tag's REMOVED status before passing the displayed value through. Additionally, the serialization format (JSON) has no concept of a "removed" tag, so even if the copy were aware, there's no way to communicate it to the paste side.

Expected behavior:
  

• Copying the "new" column of a removed tag should produce an empty value (empty string for plain text/TSV).
• For the internal JSON clipboard format, the removal intent should be preserved so that pasting can correctly delete the tag on the target rather than setting it to the old value.
• Copying the "old" column of a removed tag should still copy the original value (unchanged).