Warn when loader-bundle-env's installed tree drifts behind its lockfile

[field123]

A developer's platform/loader-bundle-env/node_modules can drift arbitrarily far behind its yarn.lock with no warning. wab keeps serving loader bundles built from the stale tree.

This is the root cause of #397. That install was from 9 Apr against a lockfile updated 27 Apr — 49 of 59 Plasmic packages were a generation behind, including the @plasmicapp/data-sources that produced the crash.

Deployments are not affected: platform/wab/Dockerfile:15 installs --frozen-lockfile, and the CI cache key in .github/actions/setup-env/action.yml:36 is hashFiles('**/yarn.lock'). This is a local-developer problem only.

Proposed fix

At wab startup, compare installed versions against lockfile pins for platform/loader-bundle-env/node_modules/@plasmicapp/* and @plasmicpkgs/*. Log a warning listing what is stale and telling the developer to run yarn setup:loader-bundle-env.

Scope the check to those two namespaces

The obvious whole-tree implementation is wrong. Measured on this repo:

Scope	Packages	Time	False positives
Whole node_modules	838	265ms	25
@plasmicapp/* + @plasmicpkgs/*	59	16ms	0

The false positives come from 76 packages that legitimately have more than one pinned version in the lockfile, so a naive name→version map misreports nested copies.

One name inside the plasmic scopes is also ambiguous — @plasmicpkgs/commerce, pinned at both 0.0.232 and 0.0.242. Accept a match against any pinned version for a given name.

Scoped this way the check is precise: it reported 49 stale before the #397 fix and 0 after.

Severity: warn, not fail

Recommend a warning rather than blocking startup. #401 hard-fails the one mismatch that actually breaks bundles; everything else here is potential-subtle-bug territory (react-web 1.0.0 vs 1.0.2, host 2.0.0 vs 2.0.1) and not worth blocking a dev server over.

Acceptance criteria

• Starting wab on a stale loader-bundle-env logs one warning naming the stale packages and the fix command.
• A tree matching the lockfile logs nothing.
• Adds no meaningful startup latency (~16ms measured).
• No false positives from packages with multiple pinned versions.