Proposal: auto-fallback to ~/.mapbox-cli when ~/.mapbox is blocked

Read the follow-up context in issue #28, then locate the CLI's configuration-directory and credential-store path selection, including handling for MAPBOX_CONFIG_DIR and MAPBOX_ACCESS_TOKEN. Done means the stated preference order is preserved, blocked ~/.mapbox cases use ~/.mapbox-cli without reading the legacy file as a token, and the both-valid case is reported.

Follow-up from #28

Idea: when the program can solve a problem, it should — not the user.

~/.mapbox can be a leftover file, not a directory. Today the CLI asks the user to move it by hand. Proposal: fall back to ~/.mapbox-cli automatically instead.

Order matters. If we just pick whichever path is free, this trap appears: login while ~/.mapbox is blocked → credentials go to ~/.mapbox-cli. User later deletes the stray file. Next run sees ~/.mapbox free, uses it, and the user looks logged out — credentials stranded in ~/.mapbox-cli.

So: prefer whichever directory already holds a valid credential store, not whichever is free.

1. ~/.mapbox has a valid store → use it.
2. Else ~/.mapbox-cli has a valid store → use it.
3. Else (neither set up yet) → default to ~/.mapbox if usable, else ~/.mapbox-cli.
4. Both valid (edge case) → ~/.mapbox wins, and the CLI says so.

Do not read the legacy file's contents as a token. Unlike MAPBOX_ACCESS_TOKEN, the user never gave it to us on purpose — it could be stale or from another tool.

MAPBOX_CONFIG_DIR stays as-is: an explicit override, no fallback.