fix(fs)!: default macOS config dir to Application Support

[mguerrero3-godaddy]

Summary

• Implementation proposal for DEVEX-984
• Use idiomatic macOS config directory resolution instead of falling back to the Linux XDG path, while still honoring an explicit XDG_CONFIG_HOME override on all platforms.

Test plan

• cargo fmt --all --check
• cargo clippy --all-targets -- -D warnings
• cargo test --all-targets

Manual verification

Setup:

# In the cli repo, temporarily override the engine dependency:
cd cli/rust
# Edit Cargo.toml → cli-engine = { features = ["pkce-auth"], path = "../../cli-engine" }
cargo build --release && cp target/release/gddy ~/.local/bin/gddy

Test WITHOUT the fix (baseline):

cd cli-engine && git checkout main
cd cli/rust && cargo build --release && cp target/release/gddy ~/.local/bin/gddy
# <command to reproduce the issue>
# Expected: <describe broken behavior>

Test WITH the fix:

cd cli-engine && git checkout <this-branch>
cd cli/rust && cargo build --release && cp target/release/gddy ~/.local/bin/gddy
# <same command>
# Expected: <describe fixed behavior>

Cleanup:

# Revert cli/rust/Cargo.toml back to:
# cli-engine = { features = ["pkce-auth"], version = "<published-version>" }

[jpage-godaddy]

Looks good, but I think we're going to unfortunately have to figure out what to do about people that already have important files in the incorrect location, because people may have created files like contacts.toml, environments.toml, etc that we don't want to skip over.

So for one, this is a breaking change, so we need to change the PR title/commits so they will release this as a breaking version number rather than the patch version bump of a fix.

We also need to figure out a migration path for the cli to fix macOS installations. Something like:

1. Check if the settings migration has already been completed (have a flag in a file somewhere so we don't repeat the migration logic every time the CLI starts)
2. If it hasn't, check if the files are in the old location.
3. If the files are misplaced, move their files to the new location
4. Write to stderr to tell the user their config files have been moved
5. Set a flag to avoid repeating the migration check

I think we'll need that figured out before we integrate this engine change into gddy; it's probably best if we have the plan in place in advance so we don't have the engine change merged into main for too long.

[mguerrero3-godaddy]

@jpage-godaddy

Good call, implemented a migration approach proposal, plus flagged this as breaking.

Proposal for the migration, on macOS at startup (before config loads):

• Checks a marker file (.cli_engine_macos_migrated) at the new location. if that's present, no-op, skip everything.
• If not present, checks the old ~/.config/{{app_id}} location. If nothing's there, just writes the marker and moves on.
• If there are files, moves every entry by read_dir, not a hardcoded list, so that contacts.toml, environments.toml, the credentials/ subdirectory, anything, all move the same way regardless of name. Idea is to not overwrite something that already exists at the new location.
• Writes a one-line stderr notice on what moved, and a separate notice if anything had to be left behind due to a name conflict (so the user knows to reconcile manually).
• Writes the marker afterward so this never re-checks on future runs (skips).
• No-op entirely if XDG_CONFIG_HOME is set, that's an explicit user override, not something we should touch.

Let me know If this closes the gap or If this requires further discussion to flag