#### Brief overview of PR changes/additions
- `61c2afd40` (#9712) made `$XDG_CONFIG_HOME/mudlet/profiles` the opt-in
marker for an isolated config root, and an empty
`$XDG_CONFIG_HOME/mudlet` no longer qualifies. It updated three
functional tests to the new recipe and missed two, so
`ProfileDeletionSafetyTest` and `ConnectionDialogCrashTest` resolved to
the real `~/.config/mudlet` and failed in `initTestCase()` on every leg
(run 31428353403). Every open PR inherits that red, because PR builds
merge the dev tip.
- Both now pre-create `mudlet/profiles`, matching the ten sibling tests
and `src/mudlet-lua/tests/README.md`. Product code is untouched.
- An empty `profiles/` still reads as a fresh install
(`anyProfilesExist()` counts subdirectories), so neither test's
first-launch expectations move.
Test case: `ctest -R
"ProfileDeletionSafetyTest|ConnectionDialogCrashTest"` against a
`~/.config/mudlet` that holds profiles - both fail on `development`,
both pass here; the full functional suite is otherwise unchanged.
Assisted-by: Claude:claude-opus-5
#### Brief overview of PR changes/additions
- Hoists the list `slot_deleteProfile()` checks a never-played profile
against out of the function to
`dlgConnectionProfiles::scmConnectionDetailFiles`, beside the file's
other `scm*` constants, and points at it from both `writeProfileData()`
implementations.
- Adds a `ProfileDeletionSafetyTest` case that sets a profile up through
the real dialog (New profile, name it, fill the connection form in,
re-select it) and fails if anything it wrote is missing from the list.
- Pins the deliberate exclusions too: a profile holding a stored
password or a typed-in character name still asks before removal.
#### Motivation for adding to Mudlet
Nothing linked that list to the ~15 places profile data gets written, so
it could silently go stale; because it is an allowlist a stale entry
only ever costs an extra confirmation prompt, but the maintenance trap
was worth closing.
#### Other info (issues closed, discussion etc)
Follows up
https://github.com/Mudlet/Mudlet/pull/9722#discussion_r3740581754 on
#9722 (fix: a profile named "." or ".." deletes every profile when
removed). No behaviour change.
**Test case:** `ctest -R ProfileDeletionSafetyTest` (20 cases). Removing
an entry from the constant makes it fail naming the file; adding `login`
makes the character-name case fail.
Assisted-by: Claude:claude-opus-5
#### Brief overview of PR changes/additions
- Validation: a typed profile name must be a folder of its own - rejects
a lone `.` and anything containing `..`. Folders already on disk stay
exempt
- Containment: `reallyDeleteProfile()` refuses any path that is not a
direct child of `profiles/`, and now checks `removeRecursively()`
instead of failing mute
- Confirmation: the "nothing to delete" shortcut no longer fires when a
map, stored password or dictionary is present
#### Motivation for adding to Mudlet
A profile named `.` or `..` turned **Remove** into a wipe: `.` resolves
to `profiles/`, `..` to the whole `~/.config/mudlet`. The name was
accepted with no error, and the confirmation was skipped because a fresh
profile looks empty - two clicks deep on the first screen every user
sees.
#### Other info (issues closed, discussion etc)
Pre-existing, not a 5.0 regression - shipped 4.22.0 behaves identically.
Dots have been allowed deliberately since 2011 (`ee1fd051c`), and
`Achaea 2.0` keeps working.
**Test case:** name a new profile `.` and press Remove - previously
every profile was deleted with no prompt, now the name is refused.
New `ProfileDeletionSafetyTest` drives the real dialog against a
temporary config dir, plus `profileFolderPath`/`profileNameUsableAsIs`
rows in `ProfileNameValidationTest`. 81/81 ctest pass.
Assisted-by: Claude:claude-opus-5
