I (Jason) am very sorry but I will be offline for the next several hours and people still have busted conflicted npm packages. Here is a workaround.
The workaround is simply to touch your document over and over (i.e. GET and then PUT it back unchanged). You can use Futon https://isaacs.iriscouch.com/_utils/ and log in as your npm user, or use curl with basic auth, or write some JS even.
Once a doc revision has a longer change history, it becomes the winning revision and mostly shadows out all other revisions. That's good enough for npm. From there an npm publish —force usually puts things right I do not want to risk writing experimental code that is modifying and merging documents in an exhausted state. That's how things go from bad to worse.
The documents are not exhausted, I am. Just to clarify.
I will be back in the office at dawn local time, which is in 7 hours where I will be rested and ready to roll out the permanent fix.
Incidentally, this works because we've got replication fixed so new conflicts shouldn't be happening. But if you still have old conflicts, they will cause problems. (Basically one revision has the metadata like version numbers and checksums, and the other revision has the attachments.) We are fixing this server-side and it's going well but the npm client is much better positioned to just blow things away and do it again.