#### Brief overview of PR changes/additions
- An empty `$XDG_CONFIG_HOME/mudlet` silently beat a populated
`~/.config/mudlet`, so a stray `mkdir` hid every profile and Mudlet ran
its first-launch onboarding as though the user were new. It also stuck:
the first such launch wrote `Mudlet.ini` into that directory, which then
kept it winning.
- The two candidate roots are now ranked (`profiles/` > `Mudlet.ini` >
exists > absent) and the stronger claim wins, with
`$XDG_CONFIG_HOME/mudlet` taking ties so a fresh install and a
deliberate opt-in both still land there. A directory that cannot be
listed counts as populated rather than empty, so a permission bit cannot
re-enter the bug.
- Creating `profiles/` is now the opt-in a test harness uses; the
`mudlet` directory alone is not, because other tooling creates that by
accident. Where both roots hold profiles, `setupConfig()` names the one
it is ignoring instead of leaving those profiles apparently gone.
#### Motivation for adding to Mudlet
Data-loss-shaped regression from #9552 "improve: honor XDG_CONFIG_HOME
for Mudlet's config directory" (`e6c268cb0`). The profiles are orphaned
rather than destroyed, but a returning user sees "5.0 wiped my
profiles". `src/mudlet-lua/tests/README.md` itself instructed `mkdir -p
"$CONFIG_DIR/mudlet"`, so following Mudlet's own test docs triggered it.
#### Other info (issues closed, discussion etc)
Test case: create `~/.config/mudlet/profiles/{AlphaGame,BetaGame}`,
`mkdir -p $XDG_CONFIG_HOME/mudlet`, launch. Before: no profiles and the
onboarding dialog. After: both profiles listed.
`ConfigDirOverrideTest` covers the resolution table including the sticky
`Mudlet.ini` state, both-populated, symlinked and unreadable
directories; each new guard was mutation-checked. The busted suite
passes 2422/0 against an isolated `$XDG_CONFIG_HOME/mudlet/profiles`
root.
Not fixed here, and pre-existing rather than 5.0 regressions:
`CredentialManager` stores passwords and the OAuth reconnect token under
`AppConfigLocation` while the config root is `confPath`, so exporting
`XDG_CONFIG_HOME` strands them, and the plaintext-password migration
reads one path, writes the other and deletes the original. Both
reproduce identically on the 4.22.0 binary and need their own migration
path.
Assisted-by: Claude:claude-opus-5
#### Brief overview of PR changes/additions
- Mudlet now honors `XDG_CONFIG_HOME` (it previously hardcoded
`~/.config/mudlet`): precedence is portable.txt (unchanged) >
`$XDG_CONFIG_HOME/mudlet` when set and absolute > legacy
`~/.config/mudlet`
- Migration guard: users who already export `XDG_CONFIG_HOME` keep their
legacy profiles (a one-time hint explains how to migrate); a stale
pre-4.19 `Mudlet.conf` leftover cannot shadow real profiles
- Test harnesses opt into isolation by pre-creating an empty
`$XDG_CONFIG_HOME/mudlet` - fixes parallel busted runs colliding on the
shared self-test profile's sqlite (locked/readonly flakes) and state
accumulating across runs
- `MUDLET_TEST_FAILURE_MARKER` isolates the shared
`/tmp/busted-tests-failed` marker; new `ConfigDirOverrideTest` (11
cases) locks the resolution table in
#### Motivation for adding to Mudlet
Proper XDG platform behavior on Linux, and hermetic parallel test runs -
proven by A/B: two simultaneous suites sharing one config dir reproduce
the sqlite flakes, isolated dirs run both green (679/0/0 each).
#### Other info (issues closed, discussion etc)
**Test case:** `export XDG_CONFIG_HOME=/tmp/x && mkdir -p /tmp/x/mudlet`
then launch - Mudlet uses `/tmp/x/mudlet`; unset it - Mudlet uses
`~/.config/mudlet` as before; run two busted suites simultaneously with
distinct pre-created XDG dirs - both green.
Assisted-by: Claude:claude-opus-4-8
