docs(devices): describe removing a working copy

content/docs/(overview)/devices.mdx

@@ -39,6 +39,8 @@ The hydration **empties the copy first** if the instance's event log now ends be
 
 A copy made by an earlier build of the core can have a different shape. The device **refuses to open it** with `wrong_schema`, deletes nothing, and says how many writes the file holds that the server hasn't taken, because only the build that made it can send them. If some are of a kind the current build no longer sends, it names the kind. [Troubleshooting](/run/troubleshooting#staying-in-step) says what to do. An app built on the core's Node or Swift binding can replace a refused copy that holds nothing unsent with an empty one; the files the copy downloaded stay. A [folder](/run/sync-a-folder#move-to-a-newer-cli) can replace its own copy itself.
 
+**An app can remove its working copy, with the unsent writes the person agreed to lose.** An app passes the number of writes the server hasn't taken that it showed the person, through the core's Node binding (`MarfaCore.removeStore`). The device removes the copy only when the copy holds exactly that number, whatever build made it: the file, its logs, the files it downloaded and its lock, and nothing else beside them. A symbolic link at one of those names is removed, never what it leads to. If the copy holds another number, or one the device can't read, the device refuses with `unsent_differs`, says the copy's own number, or that it can't read one, and leaves the copy, its logs, its downloaded files and its lock as they were. It refuses with `reading_handle` while anything else writes the copy, the app's own open copy included, so the app closes its copy first. A helper process that only reads the copy doesn't stop the removal, and keeps showing the old copy until it reopens. A folder's copy goes only with the folder, so the device refuses it with `invalid`. A path with no copy holds no unsent write, so removing it again finishes a removal that stopped part way.
+
 ## A write made offline
 
 Every write a device makes shows in its copy at once, and waits in the queue until the instance answers it. Sending the queue is a **drain**. The timeline follows one note through it.

content/docs/run/troubleshooting.mdx

@@ -281,6 +281,8 @@ The message says how many writes the file holds that the server has not taken: w
 - **None.** Every write the file holds reached the server. Run `marfa device hydrate` to build a new working copy. An app built on the core's Node binding can call `replaceRefused` instead, and one built on the [Swift SDK](/swift-sdk#replace-a-refused-copy) can call `WorkingCopy.replaceRefused(store:server:fileBudget:)`: it replaces the old file with an empty copy, so what only the old file held, such as pins, is lost. The files the copy downloaded stay.
 - **Some.** Open the file with the build that made it, run `marfa device drain` to send the writes, and use `marfa device discard` on any it refuses that you don't want. Then hydrate a new copy with the newer build. Keep the old file until you have done this, because deleting it loses those writes.
 
+An app that lets a person discard the copy instead can remove it through the core's Node binding (`MarfaCore.removeStore`), passing the count the person agreed to lose. The core removes the file, its logs, its downloaded files and its lock only if the file still holds exactly that count, and otherwise refuses with `unsent_differs` and the file's own count. [Devices](/devices#the-working-copy) explains the removal.
+
 **A folder replaces its own store.** Each folder keeps a working copy of its own, with its record of which file is which item, which files went missing, which writes and placements the server refused and which notes were purged. A folder command that writes, such as `marfa folders push`, `marfa folders pull`, `marfa folders scan` or `marfa folders watch`, handles a store from another build itself:
 
 - **None.** If the store also holds no answer the folder has yet to record, the command replaces it with a store of its own shape, says so on standard error, and carries on. The new store keeps the folder's record of its files, its first sync, the server it was filled from and `.marfa/folder.yaml`, and is filled again from the server. **The replacement changes no file and asks for no new first sync.** The command then sends each file you edited or deleted while the store was refused, takes away the file of a note put in the bin in that time, still takes away the file of a note purged before the replacement, and keeps holding a file the server refused before. If you edited a file whose note went to the bin in that time, the edit is sent as a new note.