[audit] Stray literal `$XDG_CONFIG_HOME/` directory tracks a second, drifting copy of nvim-pack-lock.json

[stanfish06]

What

The repo root contains a directory literally named $XDG_CONFIG_HOME (the raw, unexpanded string — not an expanded path):

./$XDG_CONFIG_HOME/nvim/nvim-pack-lock.json

This sits alongside the real ./nvim-pack-lock.json at the repo root and tracks its own copy of the plugin lockfile, which has already drifted out of sync with the real one — right now tinted-vim's pinned rev differs between the two files (65a38607... in the root lockfile vs 1ee9f7bb... in the stray copy).

Where

• $XDG_CONFIG_HOME/nvim/nvim-pack-lock.json (the stray file/directory)
• Introduced by commit 9ae59ea ("update", 2026-07-14) which added the whole $XDG_CONFIG_HOME/nvim/ tree in one shot; commits since then (4cc3523, 05f9a08) have updated it independently of nvim-pack-lock.json at root, so the two files no longer agree.

Why it matters

• Some tooling/session-bootstrap step is running with XDG_CONFIG_HOME unset or unexpanded (most likely a shell context where the variable expands to a literal string instead of a path, e.g. single-quoted or otherwise not substituted) and is writing vim.pack's lockfile output into a path built from that literal string, inside the repo's own working tree.
• Because both copies get committed independently, nvim-pack-lock.json (the one actually read by lua/config/plugins.lua/vim.pack) and the stray copy can silently disagree on pinned revisions — anyone diffing or reasoning about "what's pinned" can be misled by looking at the wrong file.
• It's dead weight in the repo and a confusing artifact for anyone browsing the tree (./$XDG_CONFIG_HOME/... reads like a shell-quoting bug got committed, because it is one).

Recommended action

1. Identify whatever script/hook runs nvim --headless -c 'SyncPkgs' -c 'qa' (per README.md) or otherwise writes the lockfile, and fix the environment/quoting so $XDG_CONFIG_HOME expands properly (or is set) before that command runs — this is outside the nvim config itself, likely a CI/session setup script, so it needs judgment about where that script actually lives.
2. git rm -r '$XDG_CONFIG_HOME' to drop the stray tracked copy.
3. Add a defensive .gitignore entry (e.g. $XDG_CONFIG_HOME/ or \$*) so a recurrence doesn't get re-committed by accident.

Not opened as a PR because the root cause is an external script/environment issue, not a one-line config change — removing the stray file without fixing whatever writes it would just let it reappear.