misc: tighten CI trigger conditions

[Josh-Cena]

Pre-flight checklist

• I have read the Contributing Guidelines on pull requests.
• If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
• If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

The test actions trigger too frequently, even for root files like project-words.txt that don't actually impact users. I decided to confine everything to packages/** only.

[netlify]

✅ [V2]

Name	Link
🔨 Latest commit	34dfdb9
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/626d42cacb04e300098478ab
😎 Deploy Preview	https://deploy-preview-7279--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟠 Performance	60
🟢 Accessibility	100
🟢 Best practices	92
🟢 SEO	100
🟢 PWA	90

Lighthouse ran on https://deploy-preview-7279--docusaurus-2.netlify.app/

[slorber]

don't we want CI to run again if project deps changes? (ie lockfile)

[Josh-Cena]

I thought about it, but I can't think of a case where lockfile changes without package.json changing as well. Because if package.json doesn't change, there will be no difference to our user anyways.

[slorber]

You can upgrade Yarn package resolutions and yet keep package.json intact, as long as semver ranges is respected

It's not what we do in practice when we upgrade deps so we can give it a try like that and see if it causes any problem 👍