Describe the bug
Some servers have commands (like EssentialsX's /enderchest) that open a container GUI. When you do that, ChestTracker thinks the container GUI the command opened is actually the last container you opened.

To Reproduce

1. Be on a server with EssentialsX installed with permission to use its /enderchest command.
2. Open a container.
3. Close the container.
4. Do /enderchest.
5. Close the ender chest GUI.
6. ChestTracker now thinks the container you opened in step 2 is your ender chest.

Expected Result
ChestTracker should be able to recognise that the client suddenly (not actually but as far as the mod is concerned) being told by the server to open some container is unrelated to the fact that it had previously opened and closed a container, and hadn't tried to open another one since. I can think of two solutions:

1. Have ChestTracker not try to replace the contents of a container if it knows the container has since been closed and there have been no attempts to open it between closing it and being told to open a new container (though this could maybe cause issues in very laggy environments, but a config option for this could help somewhat with that).
2. Have an "exclusion list" in the config that lets you exclude certain names based on a pattern, like "*'s Inventory" (for EssentialX's /invsee) or "Ender Chest".
3. A combination of 1 and 2 maybe? That way, if someone does indeed have a real chest named "Ender Chest" for whatever reason it'll still work if they click on it and it's obvious that it's a real container, and laggy connections don't break it like 1 might since it'd have to be named something weird as well as it being laggy.

Additional context
Nothing gets logged because it doesn't crash and works how it's currently expected to, but it shouldn't work this way because it doesn't make sense to the user. I was using mod version v1.1.17 in 1.19.2 on Quilt, if that matters.