Merge feat/dummy-key: persist anti-enumeration dummy key across restarts

# Conflicts:
#	RSYNC_COMPAT.md

README.md

@@ -522,11 +522,17 @@ deterministic per-username dummy challenge, so probing the daemon cannot
 enumerate users. Store lines are generated with
 `fastsync-server --hash-credentials <plaintext-file>` (see `RSYNC_COMPAT.md`);
 redirect that output to an owner-only (mode 0600) file, and note that legacy
-`user:SHA256HEX` stores are rejected. Two residuals are accepted: the dummy salt
-is stable within one daemon lifetime but changes across restarts, so a
-restart-gated enumeration channel remains (persisting a dummy key is out of
-scope); and the store iteration count is observable pre-auth by design, since
-the miss path must match a hit.
+`user:SHA256HEX` stores are rejected. FastSync also maintains an owner-only
+(mode 0600) `<store>.dummykey` sidecar next to the store: it holds the store-wide
+dummy key, is auto-created on first load, and must be preserved across daemon
+restarts so the dummy challenge for an unknown user stays stable (the key is
+never regenerated while the sidecar exists). If the sidecar cannot be created
+(process-substitution/FIFO store path such as `/dev/fd/N`, a read-only
+filesystem, or a missing directory), the daemon logs a warning and uses a
+transient key, so the cross-restart guarantee does not hold for those
+deployments. One residual is accepted: the store
+iteration count is observable pre-auth by design, since the miss path must match
+a hit.
 
 An `auth users` module accepts credentials only when one of two conditions
 holds: (a) the connection is an encrypted, verified TLS connection whose client