Optimizing build cache step

[williamdalessandro]

While looking for ways to optimize/shave off time from our builds, I was brought back to this ticket. This caching step didn't make any sense to me so I delved into it.

Essentially, this step was creating a cache key whose name was a mix between a hash of our package-lock file and a hash of all of our (70k+) mdx files (which would take 2-3 min to process). This key would be used to pull up a cached version of the content we have in ~/.npm and /.next/cache during the github runner process. The content in those folders are just downloaded packages, compliled js/ts files, and other things for nextjs optimization.

If a single mdx file changed, it would just invalidate the cache (even though the cache was totally good to use), and cause us to run npm install again, so we never really had the proper benefit of this cache in the first place.

This PR simplifies and narrows the scope of the files we actually care about caching the changes for. Included changes in both the build-preview process and the deploy-udr step.

[github-actions]

Vercel Previews Deployed

Name	Status	Preview	Updated (UTC)
Dev Portal	✅ Ready (Inspect)	Visit Preview	Wed Dec 3 00:56:38 UTC 2025
Unified Docs API	✅ Ready (Inspect)	Visit Preview	Wed Dec 3 00:52:18 UTC 2025

[RubenSandwich]

@williamdalessandro you are not going to see any changes in the workflow because of special security rules around the pull_request_target action trigger.

This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as the pull_request event does. This prevents execution of unsafe code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.

For example notice in your latest commit, even though you removed the .next cache it is still listed: https://github.com/hashicorp/web-unified-docs/actions/runs/19686847781/job/56394394734#step:6:4.

You will need to duplicate the GHA workflow file with a trigger of just pull_request to see the changes in this PR, as pull_request_target will always use the main branches version of it's workflow for security reasons.