While investigating T282905: Translate syntax version update and translation-aware transclusion lost I audited all code manipulating translate_metadata table. There is a small utility class TranslateMetadata. All writes to this table go through that class (there are a couple places where the table is read directly): https://codesearch.wmcloud.org/search/?q=translate_metadata&i=nope&files=&excludeFiles=&repos=
There is TranslateMetadata::deleteGroup that is only called from ApiAggregateGroups. That API module does not validate the parameter for aggregategroup when action=remove. Only restriction is that this module requires the translate-manage right. We have little above 200 people with that right on MetaWiki: https://meta.wikimedia.org/w/index.php?title=Special:ListUsers&offset=&limit=500&group=translationadmin
I was able to confirm that deletion of any group's metadata is possible using this module. The code has innocent looking // @todo Logging, which is really unfortunate in this case, because I can't for sure say that this is or is not the cause for the parent issue.
It seems the most likely cause, however, by ruling out other possibilities:
(1) The value was never saved in the first place. This is implausible because we have the log entries, other metadata in other tables and nothing in Logstash. Why would writes to this table silently fail, but not the other writes? In addition achive.org seems to confirm that the metadata was saved and was effective at some point.
(2) The value was deleted by calling TranslateMetadata::set with false as the value. When marking the page for translation, type declarations would prevent false for appearing for all the different tmd_key values.
(3) Page is moved or deleted. This would certainly leave log entries and other visible traces.
I think it would be good to silently patch do=remove for action=aggregategroups to do nothing but add logging that would identify the attacker (if any).
It would be really helpful if we could find DELETE statements for translate_metadata from binlogs/query logs (if we have any). This would help to find the extent of this issue and hopefully confirm the cause too.