fix(fuse): keep pinned files on disk through remote changes

A remote change to a pinned file called `ContentCache::evict`, which does
not check pins, and only the pin request itself ever downloaded anything.
An edit from another device, or even a rename, left the file listed as kept
offline with no copy, so the next read downloaded it or failed without a
network. A file added to a pinned folder elsewhere was never downloaded,
and a folder pin whose downloads failed while offline never retried them.

A remote change no longer evicts a pinned file's copy. The copy is checked
against the revision's (mtime, size), so a newer revision does not read
it, and a rename keeps the mtime (B123), so the copy stays valid. A new
pdfs-pin-keeper thread checks pins again and downloads files that are
missing or stale:

- the pins a batch of remote events changed, after the batch's listings
  are dropped, including a pinned folder that gets a new file;
- every pin at startup, when the link returns, and after the event feed
  loses continuity;
- a file whose version is restored.

Failed downloads retry with a backoff of 30 s to 30 min. Pinning and the
keeper settle a provisional size first: a copy stored under the
ciphertext size never matched the plaintext it holds.

Fixes B282.

docs/ARCHITECTURE.md

@@ -467,6 +467,7 @@ both with `pdfs_core::search::relevance_score`, so the prompt can merge them int
 | `pdfs-sync`, `pdfs-sync-poll` | Mirror passes and the remote poll (§7) |
 | Tokio runtime | Remote calls, and the Drive and photos event streams (§6) |
 | `pdfs-online-probe` | Probes Drive while offline |
+| `pdfs-pin-keeper` | Checks pins once a second for work: every pin at startup, when the link returns and after the event feed loses continuity, and the pins a batch of remote events changed. Downloads files kept offline that are missing or stale; failures retry with a backoff of 30 s to 30 min (`docs/BUGS.md` B282) |
 | `pdfs-supervisor` | Logs workers that hold one job for minutes, a queue that stops draining, and control requests that never return; samples memory; pings the systemd watchdog only after a round trip over the control socket succeeds (`WatchdogSec=120`) |
 | `pdfs-conflict-sweep` | Optional. After 30 s, then every 5 minutes, finds `(sync-conflict …)` copies identical (size and SHA-1) to their original. `conflict_sweep` decides: `off`, `report` (default) or `enforce`, which trashes them after re-checking each one |
 | Smaller helpers | `pdfs-localindex` (home index for search), `pdfs-pause` (ends a timed pause), `pdfs-similar` (similar photos, on request), `pdfs-diagnostics` |

docs/BUGS.md

@@ -109,6 +109,7 @@ a live account since.
 
 | Entry | Title |
 |---|---|
+| [B282](#b282--a-file-kept-offline-is-downloaded-again-after-a-change-made-elsewhere) | A file kept offline is downloaded again after a change made elsewhere |
 | [B281](#b281--a-file-in-a-synced-folder-cannot-be-kept-offline) | A file in a synced folder cannot be kept offline |
 | [B280](#b280--uploading-a-batch-of-large-photos-swaps-the-machine-until-the-daemon-is-killed) | Uploading a batch of large photos swaps the machine until the daemon is killed |
 | [B279](#b279--after-a-watchdog-kill-the-mount-never-comes-back) | After a watchdog kill the mount never comes back |
@@ -384,6 +385,45 @@ a live account since.
 
 Newest first.
 
+### B282 — A file kept offline is downloaded again after a change made elsewhere
+
+**Status:** Fixed, not verified live
+**Found:** 2026-11-13, while looking into B281. Nothing downloaded a pinned file again after the
+pin had downloaded it once.
+**Where:** `apply_event` in `crates/pdfs-fuse/src/background.rs`; the new pin keeper in
+`crates/pdfs-fuse/src/keeper.rs`
+
+**Repro:** Pin a file, then change it from another device. The event deletes the cached copy.
+The file stays listed as kept offline, `cached` is false, and the next read downloads it, or
+fails without a network. Rename or move it elsewhere and the same happens, though its content
+did not change. Add a file to a pinned folder from another device and it is never downloaded.
+A folder pin whose downloads failed while the link was down never retries them.
+
+**Cause:** A remote change to a known node called `ContentCache::evict`, which does not check
+pins, and only the pin request itself downloaded anything. The copy was also stored under the
+size the listing held at pin time. That is the ciphertext size until the size upgrade lands
+(B12), and a copy stored under it never matches the plaintext it holds.
+
+**Fix:** A remote change no longer evicts a pinned file's copy. The copy is checked against the
+revision's `(mtime, size)`, so a read of a newer revision does not take it. A rename keeps the
+revision's mtime (B123), so the copy stays valid. A pin keeper thread checks pins again and
+downloads files that are missing or stale:
+
+- the pins a batch of remote events changed, after the batch's listings are dropped;
+- a pinned folder that gets a new file;
+- every pin at startup, when the link comes back, and after the event feed loses continuity;
+- a file whose version is restored.
+
+Failed downloads are tried again with a backoff from 30 s to 30 min. Pinning settles a
+provisional size before it stores the copy.
+
+**Test:** `a_file_kept_offline_stays_on_disk_through_changes_made_elsewhere` in
+`crates/pdfs-fuse/src/sim/daemon.rs`. Another device edits a pinned file and a file in a pinned
+folder, and adds a file to that folder. The test waits until all three are cached, then reads
+them with the link down. With the keeper disabled, it fails with all three uncached.
+
+---
+
 ### B281 — A file in a synced folder cannot be kept offline
 
 **Status:** Fixed, not verified live

docs/CHANGELOG.md

@@ -59,6 +59,13 @@ Existing folders stay device backups. Older builds cannot open the upgraded data
   Proton Drive mount, so the copy in the synced folder was downloaded again by every program that
   read it.
 
+- **Files kept offline stay on this computer when they change elsewhere** (B282). A change from
+  another device, even a rename, deleted the copy of a file kept offline, and nothing downloaded
+  it again, so the next read downloaded it or failed without a network. Files added to a folder
+  kept offline from another device were never downloaded. The copy now stays until the new
+  version is downloaded, which happens on its own. Files kept offline are also checked at
+  startup and when the connection returns, and failed downloads are tried again.
+
 ## [3.7.0] — 2026-11-02
 
 Schema: **44**, unchanged.