Avoid stale room ownership when pasting copied objects

[Copilot]

Rare object paste operations in Tomb Editor could fail with an "object already belongs to another room" exception, after which the paste would effectively behave like a move. This comes from collision checks mutating room ownership on the clipboard instance during paste preparation.

• ObjectClipboardData: stop mutating room ownership during paste preparation

  • Replace the temporary AddObject / RemoveObject probe used in MergeGetSingleObject().
  • Resolve identifier conflicts directly from current level state instead of attaching the clipboard object to SelectedRoom.

• Identifier collision handling

  • Script ID conflicts are now checked against editor.Level.GlobalScriptingIdsTable.
  • Lua name conflicts are now checked against existing level objects implementing IHasLuaName.
  • Conflicting identifiers are cleared before placement, preserving the existing paste flow without reusing the source instance.

• Result

  • Clipboard objects remain detached until the real placement step.
  • Paste no longer risks leaving the instance bound to a room, which avoids the rare exception and the follow-on "move instead of copy" behavior.

private static void ResetCollidingScriptId(Editor editor, ObjectInstance obj)
{
    if (obj is not IHasScriptID scriptObject || !scriptObject.ScriptId.HasValue)
        return;

    if (editor.Level.GlobalScriptingIdsTable[(int)scriptObject.ScriptId.Value] != null)
        scriptObject.ScriptId = null;
}

[Nickelony]

@copilot Would you be able to provide reproduction steps for the original issue? What do we have to do in order to get the original error before the fix was applied? Also, please double-check that the changes don't cause any regressions for other places in the code.

[Copilot]

@copilot Would you be able to provide reproduction steps for the original issue? What do we have to do in order to get the original error before the fix was applied? Also, please double-check ...

3454d84

I could not get a 100% deterministic UI repro in this Linux sandbox, but the pre-fix failure mode is clear:

• use a pre-fix build,
• copy a TombEngine object that carries a Script ID / Lua name (moveable, camera, sink, sound source, volume, etc.),
• paste it so ObjectClipboardData.MergeGetSingleObject() runs its collision-resolution path.

Before the fix, that method temporarily added the clipboard instance to SelectedRoom and only removed it afterwards. If that temporary probe failed before the matching remove, the later real placement step would first update the instance position and then hit room.AddObject(...) with "already belongs to another room". That is why the failed paste could look like a move.

I also re-checked regressions for the current change:

• Script ID handling still matches the old AddToRoom() collision condition by checking GlobalScriptingIdsTable directly.
• Lua name handling still matches the old CanSetLuaName() logic by checking existing level objects for the same name.
• The change is isolated to MergeGetSingleObject(); it does not alter placement, undo, flyby normalization, or imported-geometry remapping.
• GitHub Actions for this branch show no failed jobs for the current head. I also tried a narrow local test run, but this repo still hits the pre-existing Windows-only fxc.exe / powershell.exe build requirement in TombLib.Rendering in this sandbox.