In the readme, you explain that keybinds have translation keys, which can get resolved by the client when editing a sign. From looking at CytooxienDetectedMods.md however, it seems like many of these translation keys are not keybinds but just translation keys from mods with multi-language support that are using minecraft's language utils to apply the right language.

Examples of translation keys in CytooxienDetectedMods.md:
"config.torohealth.red": "Red" ToroCraft/ToroHealth lang/en_us.json
"jex.name": "Jex Client" DustinRepo/JexClient lang/en_us.json
"liquidbounce.generic.enabled": "Enabled" CCBlueX/LiquidBounce lang/en_us.json

None of the above seem to be related to hotkeys. If this is the case and sign edit replacing for all translation keys is possible, your mod is detectable since you block all translation keys except the vanilla hotkey translation keys, meaning you also block all vanilla non-hotkey translation keys from signs. This is just a theory and It's probably much easier for you to test this than for me to build a test setup from scratch.

This is a good issue, I didn't look that closely at all the keybinds requested by Cytooxien. However, they are all sent as a KeybindTextContent object, so the mod filters them. However, I dug a bit deeper into the minecraft code, and it turns out that Minecraft first tries to resolve for a keybind translation when receiving a KeybindTextContent, but if that fails, it also tries to look for a generic translation. This exposes all mods which have custom translations, not just those which use keybinds.

For now on Cytooxien this shouldn't be a problem, as the translation keys are sent as a keybind. Still, for future-proofing the mod I will change it, so that the mod also filters any TranslatableTextContent objects.

Thanks for creating this issue, filtering for generic translations has been added in v1.1.0.