CRUSH_GLOBAL_DATA does not relocate the provider catalog, so an isolated run still writes the real data dir

[arcaven]

CRUSH_GLOBAL_DATA was added in #1661 so a run could "simulate Crush being opened for the first time on the machine," and it very nearly does. The gap is that the provider-catalog refresh ignores it and writes providers.json and hyper.json into the real data directory anyway, so a test or CI run that sets the variable still touches the developer's own state. It looks worth closing because the variable already works for everything else, which makes the exception easy to trip over and easy to miss.

Expected. With CRUSH_GLOBAL_DATA pointed at a scratch directory, no writes land in the default data directory.

Actual. projects.json is correctly written under the scratch directory. providers.json and hyper.json are rewritten in ~/.local/share/crush/ instead.

Repro on v0.88.1, darwin/arm64:

D=$(mktemp -d)
find ~/.local/share/crush -type f -exec stat -f '%m %N' {} \; | sort > /tmp/before
cd "$D" && CRUSH_GLOBAL_DATA="$D/data" crush run 'ok' >/dev/null 2>&1
find ~/.local/share/crush -type f -exec stat -f '%m %N' {} \; | sort > /tmp/after
find "$D" -type f          # $D/data/projects.json  <- honoured
diff /tmp/before /tmp/after # providers.json, hyper.json <- mtimes moved

Byte sizes are unchanged, so this refreshes rather than corrupts; the cost is that an isolated run is not isolated.

CRUSH_DISABLE_PROVIDER_AUTO_UPDATE=1 suppresses it, verified in the same shape (real directory unchanged). That is a good workaround and it does suggest the auto-update path resolves its destination independently of the override rather than through the same lookup the rest of the data directory uses.

Would it make sense for the provider-catalog write to resolve through CRUSH_GLOBAL_DATA as well, so #1661's "first time on the machine" simulation holds for the whole data directory? Happy to follow up with a PR if that is the direction you want.