Linux: settings.json (SellerId/TenantId/ClientId) not visible to any subsequent msstore invocation after reconfigure, despite file being correctly written

Environment

• MSStoreCLI-linux-x64.tar.gz from the latest release (v0.4.2, commit 9731b77)
• Runner: GitHub Actions ubuntu-latest
• Invoked non-interactively inside a dbus-run-session with a freshly-unlocked ephemeral gnome-keyring (headless Linux needs a Secret Service for reconfigure's credential write — that part works correctly once bootstrapped)

Repro

msstore reconfigure --verbose \
  --tenantId "$TENANT_ID" --sellerId "$SELLER_ID" \
  --clientId "$CLIENT_ID" --clientSecret "$CLIENT_SECRET"
# → "Configuration saved!" / "Awesome! It seems to be working!" (success)

cat "$(dirname "$(msstore info --verbose 2>&1 | grep -oP '(?<=Settings File Path: ).*' || true)")"/settings.json
# confirmed present, valid JSON, correct values (see below)

msstore info --verbose
# → crit: MSStore.CLI.Program[0] SellerId is not set.  (exit 255)

Any second msstore invocation after a successful reconfigure fails identically — this isn't specific to publish. msstore info (read-only, no side effects beyond loading+printing the config) fails the exact same way.

What I've directly confirmed, not assumed

1. reconfigure writes a complete, valid settings.json. Read the file directly (same shell, immediately after reconfigure exits, before the next msstore invocation): {"SellerId":<real int>,"TenantId":"<real guid>","ClientId":"<real guid>"} — fully populated, valid JSON.
2. The file is confirmed present and readable via ls -la at the exact moment right before the next invocation starts — same shell, same pwd, non-empty, correct permissions/owner.
3. XDG_DATA_HOME has no effect. Exported it explicitly (export XDG_DATA_HOME="$HOME/.local/share") across two separate runs — the resolved settings path was identical with or without it.
4. CWD/workspace-path complexity ruled out. Tried both the (deeply-nested) GitHub Actions workspace path and a short, flat, explicit cd /tmp/msstore-cwd before every invocation. Both reconfigure and the failing second invocation report the identical Content root path in their own --verbose logs each time. Same failure either way.
5. No exception is ever logged. With --verbose on, I'd expect to see "Something in the config file seems wrong..." (from MicrosoftStoreCLI.InitAsync's catch block around LoadAsync) if deserialization threw. It never appears — only the direct "SellerId is not set." critical log. Per ConfigurationManager<T>.LoadAsync (clearInvalidConfig: false is what InitAsync passes), the only way to reach config.SellerId == null with no exception logged is File.Exists(_settingsPath) returning false for that second process — despite point 2 above showing the file present via a shell command in the identical working directory milliseconds earlier.

Question for maintainers

Given (1)-(5), this looks like Environment.SpecialFolder.LocalApplicationData (or the File.Exists check specifically) resolving non-deterministically or incorrectly between separate process invocations of the self-contained Linux build — not anything under the caller's control (env vars, CWD, timing all ruled out as far as I can test from the outside). Is this a known issue with the self-contained/AOT Linux build specifically? Happy to provide any additional diagnostics if there's something specific you'd like captured (e.g. strace of the File.Exists/stat calls, if that's useful) — I don't have visibility past what the CLI's own --verbose output and shell-level file checks can show.