https://gitlab.synchro.net/main/sbbs/-/commit/bf13f8b7ef20527e27b1868f
Modified Files:
docs/superpowers/specs/2026-08-02-syncretro-save-restore-design.md exec/load/door_deploy.js syncretro_lib.js syncretro_lobby.js src/doors/syncretro/LAUNCHER.md M3_MULTICORE.md
Log Message:
syncretro: stop stating one BBS's storage topology as a general fact

Several files asserted that the install and data_dir are an SMB mount shared with a second host. That is true of one system and of no other by default,
and it was being used as the premise for design decisions in documents and comments a sysop reads to understand their own install.

The decisions were right; the reasoning was overstated. A Synchronet install CAN be shared by more than one host and CAN sit on a network filesystem, and that possibility is enough to justify an append-only activity log, a derived cache that tolerates a lost update, and a deploy that refuses to rename over
a running binary. Each now rests on that rather than on one site's layout.

The measurements stay, framed as what they are: a remote Windows node paying
a round trip per cartridge, CIFS reporting an mtime a second off from the
local view, a rename onto an executing file deleting the target and then failing. Those are observations worth keeping, and worth not generalizing
into claims about every BBS.

Also drops the same premise from the suspend/resume design, where it was load-bearing for a claim that did not need it: an arcade cabinet's high-score table is already lost to a concurrent player on any install, with no network filesystem involved, because two nodes on one machine are enough.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)