As much as I'd like to do this, "we" (you may not have been there) absolutely decided to put it back to next quarter. I know because I spent quite a bit of time taking all the mentions of Wikidata out of the error messages (when we thought the change would be in Q3) and then putting them all back in (when we decided to put it off). So you need to talk to @Catrope about why we did that.

There are a couple issues with this that make it more complicated than I thought:

1. The Wikidata revision ID is only in rc_params, so it's not joinable. It's also in wb_changes, but that doesn't have the rc_id or anything allowing joining to recentchanges AFAICT.
2. The ORES tables are per-wiki, so we wouldn't be able to join recentchanges from this DB to the wikidatawiki ORES table.

We could potentially solve 1 by one of:
1a. Putting the real Wikidata revision ID into rc_this_oldid. Not sure if this is a good idea. This is an ID from a totally different wiki in a column that expects one from the current wiki, but you can distinguish based on rc_type.
1b. Adding rc_id to wb_changes.

We could potentially solve 2 by one of:
2a. Fully centralizing the relevant ORES tables, with a 'wiki' column name, then mirroring them everywhere.
2b. Mirroring just the Wikidata ones to the client wikis.

Hmm, if only we had support for ORES scores for non-revision objects (like log entries or RC rows), then this'd be much easier.

@Mattflaschen-WMF, is this blocked?

@jmatazzoni There's nothing inherently blocking it, but if this is (potentially) a priority, we should have an architecture discussion. The best solution is not obvious, though @Catrope's approach is worth considering.