The purging docs have all the gory details, but to specifically answer your question, I can say that this functionality is designed for pretty much this exact situation!
Basically, the CHT purging functionality works by having the server periodically evaluate all the docs on the server against the set purge configuration to determine which docs should be considered “purged”. If a doc is found on the server that should be “purged”, it is not deleted or removed from the server (actually the doc is not modified at all). Instead a record is made in a separate purge database that designates that document (in the medic database) as “purged”.
Then, the next time the offline client syncs with the server, it will also sync the purge database. The client will then use the information in the purge database to determine if any of its existing docs (ones that were already synced to the server) should be removed (purged) from the device. New unsynced docs on the client will never be purged since the determination for which docs to purge is done by the server. So, there is no chance of data loss because data on the server remains untouched by the purging process and data on the client will not be purged unless it is already synced to the server. The key is to determine exactly what data needs to stay on the client device and set the purging config accordingly. If you purge too much from the client, then the users might not have the historical context they need to properly carry out their tasks. If you do not purge enough, then the large number of docs will slow down the device! (At 10k records, the CHT starts warning against even logging in as the user). Also note that purged documents will not be included in the initial sync to a client device if, for example, the user logs in on a new device.
This tread might be worth a read since it contains a lot of discussion of similar circumstances (though I don’t think the replication_depth configuration is applicable to your case since do to your flat hierarchy).