chore: weekly dependency security refresh (nanoid 3.3.17 -> 3.3.18, GHSA-2v37-7h3g-55p8)

[Jayanth Reddy Bujula (jbujula)]

Opened by hand from the branch that the first run of the new weekly automation (#1441) pushed. The workflow itself could not open it - see "Why this was opened manually" below.

Run: https://github.com/microsoft/powerplatform-build-tools/actions/runs/31760462499

What this changes

package-lock.json only. No package.json change, so no dependency range moved - this is purely a lock refresh within ranges that were already declared.

Why it matters

It resolves GHSA-2v37-7h3g-55p8 (nanoid < 3.3.18, HIGH):

	main	this PR
nanoid	3.3.17	3.3.18

This is the advisory I previously documented on #1433, #1440 and #506 as not currently fixable: the nanoid override was already ^3.3.17, so the caret always admitted the fix, but 3.3.18 had not been mirrored to packagefeedproxy.microsoft.io even though upstream had tagged it. The mirror has since synced, and the workflow picked it up on its very first run with no human involvement.

That is exactly the gap this automation was built to close: Dependabot cannot see npm overrides, so an advisory whose fix is already admitted by an existing range would otherwise sit unnoticed until S360 re-raised it.

Verification

All workflow steps passed before the PR step:

• npm ci
• npm update
• scripts/audit-overrides.js --write - no range needed raising
• Build and test - passed

Why this was opened manually

The final step failed with:

pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest)

This is an org/repo Actions policy, not a workflow bug - Settings -> Actions -> General -> "Allow GitHub Actions to create and approve pull requests" is disabled. The branch push succeeded; only PR creation was refused.

I am sending a separate PR to make the workflow degrade gracefully when that policy is in force, so a future weekly run surfaces an actionable link instead of a red X. If an admin enables the setting, no further action is needed and subsequent runs will open their own PRs.

[Jayanth Reddy Bujula (jbujula)]

Re-verified today (Aug 17) — this PR is still current and still the right one to merge.

A fair question was whether this had gone stale, since the weekly job has run again since. It has not, in any way that matters.

Still applies cleanly

package-lock.json is the only file that differs from main. Every other blob SHA on this branch is byte-identical to main, so there is nothing to rebase.

Ref	package-lock.json
main	f88070a
this PR	b46ff24
today's bot/dependency-refresh-20260817	b1eb188

The newer branch adds nothing security-relevant

Today's scheduled run produced a third lock. Diffing it against this PR, only 5 packages differ, all unrelated patch bumps:

1.0.12  -> 1.0.13   @tsconfig/node10
5.5.0   -> 5.5.1    default-browser
2.3.1   -> 2.3.2    es-module-lexer
3.5.11  -> 3.5.12   json-with-bigint
2.0.11  -> 2.0.12   ohash

Critically, the security fix is identical in both:

origin/main                          -> nanoid 3.3.17
origin/bot/...-20260814 (this PR)    -> nanoid 3.3.18
origin/bot/...-20260817              -> nanoid 3.3.18

npm audit --package-lock-only on both branches: 0 critical / 0 high / 0 moderate, 6 known dev-only lows (elliptic chain).

Why merge this one rather than the newer branch

This PR has green CI. The 20260817 branch has no PR at all - the scheduled run could not open one (see #1462), so nothing has ever been built or tested from it. Merging the reviewed, CI-verified branch is the safer path; the 5 cosmetic bumps above will be picked up by the next weekly run anyway.

Once this merges, bot/dependency-refresh-20260817 is stale against the new base and should just be deleted rather than merged.