fix(lint): restrict cache lock-file glob to repo root

[topcoder1]

hashFiles('**/package-lock.json') matches lock files in subdirectories (e.g. frontend/package-lock.json), but actions/setup-node looks for the lock at the repo root unless cache-dependency-path is set. When a repo has only a subdir lock, setup-node sets the npm cache key based on the subdir lock then fails with 'Dependencies lock file is not found in /home/runner/work/REPO/REPO'.

Discovered during fleet rollout — broke the prettier job in 8 repos with frontend/ subdir layouts (finsight, techrecon, dev-utils, attaxion_marketing, inbox-superpilot-marketing, marketing-platform, wxa-mcp-server, wxa_marketing).

Fix: restrict hashFiles to root-level locks. Repos with only subdir locks now skip the cache (slower first install, but the prettier job actually runs).

Future improvement: expose cache-dependency-path as a workflow input so callers can point setup-node at their subdir lock for faster CI.

[claude]

Bug: yarn.lock in the hash check will trigger the same "lock file not found" error for yarn-only repos.

actions/setup-node with cache: 'npm' looks for package-lock.json or npm-shrinkwrap.json at the repo root — it does not accept yarn.lock as proof of an npm install. So a repo that has only yarn.lock at root will:

1. Hash it → non-empty → expression evaluates to 'npm'
2. setup-node searches for package-lock.json / npm-shrinkwrap.json at root
3. Neither exists → "Dependencies lock file is not found" — the exact error this PR is fixing

Since the cache type is always hardcoded to 'npm', only npm lock files should gate the check:

Suggested change

	cache: ${{ hashFiles('package-lock.json', 'npm-shrinkwrap.json', 'yarn.lock') != '' && 'npm' || '' }}
	cache: ${{ hashFiles('package-lock.json', 'npm-shrinkwrap.json') != '' && 'npm' || '' }}

[claude]

Flagged 1 issue inline — yarn.lock in the hashFiles list will re-trigger the same "lock file not found" error for yarn-only repos when cache is hardcoded to 'npm'.