This looks like a bad design when we want to push the document to server and then update it on server but dont want that document back to client and then push again. Naturally this is conflicting situation.
I will recommend to create a new document id for this document which one can understand on the server side.n for example lets say type of the document is type1, device is d1 and time stamp is t1 then I will create a document id as type1::d1::t1 and then have these fields in the json also having a channel if required.
Then when I will push this document it will always be a new document. Now even if an update is done on server I am not listening to that update and this will not come down. Second time I will again want to push the document but the timestamp will be different. So here you are its a new document.
The problem with this approach is that it can increase the number of documents on the server side. For that when the processing on the server side is done by a background process it can purge the document using admin API.
In local you will need to write a purge mechanism also. I can suggest using ttl on local and expiry on sync gateway but then it should be based on the business logic. Like one will want to purge from local only when the document is synced to server. And purge from server only when the processing is done.
I hope this will help you creating a better design.