[AlxcBTW]

Refs anyplaynet/launcher#263.

Cause. The net service keeps the sign-in in the system store. On Windows (Credential Manager) and Linux (Secret Service) that entry does not depend on which binary reads it; I ran launcher 0.3.8 then 0.3.9 twice on one profile against a local cloud and the sign-in carried over, and this PC's network.log shows it surviving 0.2.4 to 0.3.4. On macOS the keychain item can be read only by the program that created it, and the launcher writes a new ad-hoc-signed anyplay-net-<version>-<size> for every version (release.yml: "signed ad hoc"), so every update meets an item it may not read. That is not reproduced here (no Mac); it is the one mechanism that differs between an update and a plain restart.

Changes.

• macOS keeps the sign-in in signin-<cloud>.json (owner-only) in the data folder. A sign-in left in the keychain by an older version is read once and moved when this build may read it; a sign-out also removes that item.
• Saves still queued when the process ends are waited for (wait_saved, 3 s) so a rotated refresh token reaches the store before the launcher restarts into the new version. Before, the detached save thread could be cut off.
• network.log now says why a saved sign-in is not used: store in use, no entry, store unreadable (with the OS error), unusable content, resuming device N, and the existing "saved sign-in not accepted: ".
• Tests: a sign-in saved by one version is found by the next; missing is told apart from unreadable.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}