SkullKey v1.12.3 — store logins land where they are read from

Signing in to Epic, GOG or Amazon appeared to do nothing: the store kept asking for a login even though the credentials had been written to disk. They were — one directory away from where SkullKey looked for them.

Fixed

• Store logins were written outside the account space they are read from. SkullKey keeps each Steam account's store logins under accounts/<steamid>/, resolved by scripts/settings.sh. The login helpers are launched directly by Steam and source only their own store's settings.sh, where the account directory silently fell back to the runtime root. So legendary auth wrote to <runtime>/legendary while the status check read accounts/<steamid>/legendary and answered <not logged in> forever. All three stores shared that fallback, which is why all three behaved the same way.
• Existing installations recover without signing in again. Credentials and databases stranded in the runtime root — or in the default space used while Steam is not yet running — are adopted by the active account. Only what the account space is missing is moved: nothing is overwritten, nothing is deleted. A store directory that already exists is completed entry by entry, which matters in practice: a legendary status leaves an empty legendary/ behind, and refusing the recovery because of it would leave you signed out with the credentials sitting next door.
• The Epic login window no longer reports a failure on every page it loads. It parsed each finished page as JSON, including the sign-in form, filling the log with Expecting value: line 1 column 1 (char 0) and making ordinary navigation look like a fault.

Thanks to @tobal37, whose diagnostic output located the stranded user.json and settled this (#3).

Full Changelog: v1.12.2...v1.12.3