This looks like the result of a subtle-but-known bug in revision pruning that hasn't been properly fixed yet in 1.x. A resolved conflict can get its history pruned away over time, which leads to a false conflict appearing, which leads to the app creating another revision to resolve it, and then that can later end up as an other false conflict.I'm not involved in 1.x development anymore, so I don't know what the prognosis is for fixing this bug. There is a fix in .NET, where it was originally reported, but it hasn't been ported to the other platforms yet (here's the corresponding open iOS/Mac issue.) I suggest commenting there if getting this fixed is important to you.
// There are no branches, so just delete everything below minGenToKeep:
if (![_fmdb executeUpdate: @"DELETE FROM revs WHERE doc_id=? AND revid < ? AND current=0 AND sequence NOT IN (SELECT parent FROM revs WHERE doc_id=? AND current=1)", @(docNumericID), $sprintf(@"%u-", minGenToKeep), @(docNumericID)]) {
AND sequence NOT IN (SELECT parent FROM revs WHERE doc_id=? AND current=1)
Sorry to send you on a wild goose chase!
And now I don't understand what's going on with that database. :(
* This is a perfect example of why we're moving to common core code in 2.0!