[Bug]: Adding (or searching for) tags gets increasingly slower in the same session (running process)
### Checklist

- [x] I am using an up-to-date version.
- [x] I have read the [documentation](https://github.com/TagStudioDev/TagStudio/blob/main/docs/index.md).
- [x] I have searched existing [issues](https://github.com/TagStudioDev/TagStudio/issues).

### TagStudio Version

main

### Operating System & Version

Windows 10

### Description

Updating a library, adding tags to new entries gets increasingly slower over time.

Some details in hopes they help:
Library has around 300~ tags, 1200~ existing entries
Slowness becomes pretty much unbearable (tag search takes >5 seconds) after like 5-6 new entries, which each receive maybe 8~ tags.
Closing the library (keeping the application open) and reopening the library does not help.
Even clearing the search_field input, causing it to search for *all tags* takes seconds after use, whereas this is near instant on a fresh start of the process.
Closing the process and reopening, then performing the exact same search is 10x faster

### Attempted fixes / debugging information

I've noticed search gets run for every keypress in the search_field, which I've made a local change for using QTimer as a debounce timer but that didn't make noticeable improvements (I can possibly PR this if that seems interesting to you).
Essentially it waits 225ms after a keypress to perform the search, getting canceled by every subsequent keypress, so hopefully when the name is already known by the user, we can perform a single tag search, at the end.

I suspect there's a memory leak somewhere, or an infinitely growing list that is making every subsequent iteration take increasingly longer, but I'm not  familiar enough with the project to find this.

Also the logs didn't seem to provide much useful information to debug this.

### Reproduction

I made a reproduction, all tags are obfuscated (replaced with numbers) because the data is personal.
All entries are replaced with empty `.txt` files

https://drive.google.com/file/d/1QZ86CO6JzLVMQlm8kZRk9675_-l2q98o/view?usp=sharing

Note: I think the size of the tags or the size of the search matters in reproducing the issue, the real tags are about 8-12 characters wide.

1. Open the library (I noticed the `folders` contains an absolute path, so I'm not sure the repro is sharable without some manual editing ?)
2. Add these tags to each entry separately:
```
12
23
34
45
56
78
89
90
```
*using the keyboard, pressing enter inbetween, no cursor is involved other than pressing "Add Tags"
3. By the 8th~ entry you will notice it takes increasingly longer to complete all these steps for each subsequent entry
[Bug]: Adding (or searching for) tags gets increasingly slower in the same session (running process)
### Checklist

- [x] I am using an up-to-date version.
- [x] I have read the [documentation](https://github.com/TagStudioDev/TagStudio/blob/main/docs/index.md).
- [x] I have searched existing [issues](https://github.com/TagStudioDev/TagStudio/issues).

### TagStudio Version

main

### Operating System & Version

Windows 10

### Description

Updating a library, adding tags to new entries gets increasingly slower over time.

Some details in hopes they help:
Library has around 300~ tags, 1200~ existing entries
Slowness becomes pretty much unbearable (tag search takes >5 seconds) after like 5-6 new entries, which each receive maybe 8~ tags.
Closing the library (keeping the application open) and reopening the library does not help.
Even clearing the search_field input, causing it to search for *all tags* takes seconds after use, whereas this is near instant on a fresh start of the process.
Closing the process and reopening, then performing the exact same search is 10x faster

### Attempted fixes / debugging information

I've noticed search gets run for every keypress in the search_field, which I've made a local change for using QTimer as a debounce timer but that didn't make noticeable improvements (I can possibly PR this if that seems interesting to you).
Essentially it waits 225ms after a keypress to perform the search, getting canceled by every subsequent keypress, so hopefully when the name is already known by the user, we can perform a single tag search, at the end.

I suspect there's a memory leak somewhere, or an infinitely growing list that is making every subsequent iteration take increasingly longer, but I'm not  familiar enough with the project to find this.

Also the logs didn't seem to provide much useful information to debug this.

### Reproduction

I made a reproduction, all tags are obfuscated (replaced with numbers) because the data is personal.
All entries are replaced with empty `.txt` files

https://drive.google.com/file/d/1QZ86CO6JzLVMQlm8kZRk9675_-l2q98o/view?usp=sharing

Note: I think the size of the tags or the size of the search matters in reproducing the issue, the real tags are about 8-12 characters wide.

1. Open the library (I noticed the `folders` contains an absolute path, so I'm not sure the repro is sharable without some manual editing ?)
2. Add these tags to each entry separately:
```
12
23
34
45
56
78
89
90
```
*using the keyboard, pressing enter inbetween, no cursor is involved other than pressing "Add Tags"
3. By the 8th~ entry you will notice it takes increasingly longer to complete all these steps for each subsequent entry