fix: Let the weekly bump write its own lockfile

[ecv]

Summary

The weekly job that moves the portal onto each new Backstage release has failed every run since July, so no update has reached review in two months.

Yarn refuses to rewrite a lockfile whenever it detects a build environment, and the update step has to rewrite one to install the new versions.

This turns that restriction off for that single step and adds a fresh check afterwards, so the job finishes while an inconsistent lockfile still fails it rather than reaching a pull request.

Test plan

• The weekly run finishes and opens a pull request carrying the new Backstage versions
• The lockfile that run produces passes a clean install without modification

Fixes #77

https://claude.ai/code/session_01QV419URMnKWckY8s6j4Dwi

[ecv]

Run against a clean clone of main at 081dd74, Node 22.23.2 and Yarn 4.13.0, with CI=true and GITHUB_ACTIONS=true exported so Yarn sees what a runner shows it.

Reproducing the current job, the failure lands in the second step and matches the scheduled run of 7 September line for line.

$ yarn install --immutable
exit=0
$ yarn backstage-cli versions:bump
Running yarn install to install new versions ✖
➤ YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.
exit=1

The peer-dependency warnings are not what fails it. All six of them, the jsdom range, the react and react-dom ranges, and the missing @types/react and jest in the two workspaces, print inside the immutable install one step earlier that exits zero. Warnings do not fail an install. YN0028 does, and it fires because versions:bump shells out to its own yarn install, which inherits enableImmutableInstalls from Yarn's CI autodetection.

The discriminating test holds everything else fixed and changes only that setting. Same tree, same warnings, same command.

$ YARN_ENABLE_IMMUTABLE_INSTALLS=false yarn backstage-cli versions:bump
Upgraded from release 1.52.0 to 1.54.7
Version bump complete!
exit=0

The full sequence this change installs, run end to end from a clean tree.

$ yarn install --immutable                                          exit=0
$ YARN_ENABLE_IMMUTABLE_INSTALLS=false yarn backstage-cli versions:bump   exit=0
$ yarn install --immutable                                          exit=0

The third step is the one that matters for the concern about trading a visible failure for a silent one. It runs immutably against the lockfile the bump just wrote and accepts it unchanged, so the resulting pull request cannot carry a lockfile that a clean install would reject. Nothing is relaxed for the committed lockfile, which is still verified immutably before the bump.

What the bump produced on this run, for scale: Backstage 1.52.0 to 1.54.7, touching backstage.json, the root manifest, both workspace manifests and the lockfile, with breaking-change notes on five packages. None of that is committed here. This change carries the workflow fix alone and lets the job open that pull request on its own.

actionlint passes on the edited workflow.

One unrelated observation, recorded rather than fixed here. A plain install reformats a config-schema block in the app workspace manifest, so any install leaves that file dirty. It fails nothing and it rides along in the bump diff.