Firestore is great value and good stuff to work with from a noSQL perspective. I am a happy user.
As to the offline stuff and syncing, it depends on the syncing mechanism. You can have realtime coolness with firestore, but you can also do read/write once. Then it just acts like any endpoint database. It’s just that the API does not need to be REST/http.
As to Firestore persistance feature, this is only intended to cover for flaky connections. NOT offline usage. Not sure where it is documented, but one of the many cool videos by Firebase it is really stressed not to use it for that purpose.
I did work on an offline first app myself but reverted to realtime online anyway (with persistence on) as I need the users to be online for auth anyway. Setting up syncing manually can become quite daunting btw. I needed both ways, which in hindsight is horror.
But if it is only about taking regular snapshots from a server and then plant it in the app, it will be easy. A simple pull of data and then overwrite the data in a local storage.
As to local db, you can also go for indexedDB. Especially if your users are on android. And then even use PWA, if you are not relying on lots of plugins. 1Mb on IndexedDB on iOS is even small. Deploying as PWA could be beneficial for your case?
I am a big fan of Firebase, but there are many other, similarly priced, solutions that do not require prying eyes of bigtech.
And looking at your other q - how to get the data in firestore. That depends where it comes from. Another app or from another server? If it is another server, you likely need Firestore functions. If it is an app you build yourself, then it is just an admin app next to a user app.
Whether you should use the same structure (marking for delete or not) I’d say, consider rethinking the data-model for the end user app - focussing on fast UI. Firestore can handle mutations pretty well under the hood and refresh what is needed. And 1Mb isn’t a lot.