#4193 S3/GCS repairUnpushedFiles: the pull it asks for after a lost last-synced index does not stop it re-uploading copies a peer deleted

repairUnpushedFiles in @swamp/s3-datastore and @swamp/gcs-datastore refuses a cache with no last-synced index, because unpushed files cannot be told apart from files a peer deleted, and tells the user to run swamp datastore sync --pull. That pull does not resolve the doubt.

The pull has no prior index to compare with, so removePeerDeletedFiles removes nothing and nothing is recorded as peer-deleted, and then saveIndex writes a last-synced index. If the cache's .datastore-index.json was lost or corrupted and it holds copies of files a peer has since deleted, those copies have no last-synced entry, no live entry and no record. They classify as unpushed, and a real repair uploads and indexes them, undoing the delete.

Found by adversarial review on swamp-club#4137; not reproduced by running it. The READMEs' listed limits cover only deletions pulled before the record existed.

Possible directions

• After a pull from a null baseline, mark the cache so a repair needs explicit confirmation.
• At minimum, state this limit in the refusal message and both READMEs.