[SCF-2414] update lodash, postcss, handlebars [SECURITY]

[Gaurav0]

Resolves SCF-2414: upgrades the vulnerable lodash, handlebars and postcss versions flagged by FOSSA. It also fixes a modal bug and the CI failures that were hiding it. Version bumped to 4.10.2.

Security upgrades

Package	Before	After	Findings cleared
lodash	4.17.21	4.18.1	CVE-2026-4800, CVE-2026-2950, CVE-2025-13465
handlebars	4.7.8	4.7.10	CVE-2026-33937, -33938, -33939, -33940, -33941, -33916
postcss	8.5.6	8.5.29	CVE-2026-45623, -73646, -41305, -69153

None of these have known advisories at the new versions (GitHub Advisory Database). yarn audit reports nothing for them, and npm audit reports nothing for the packages themselves.

All three are transitive dependencies. They come in through ember-auto-import, @embroider/* and css-loader.

• This repo's lockfile: lodash gets a resolutions entry because release-it pins it exactly at 4.17.21.
• Consuming apps: resolutions don't reach consumers. To cover them, the three packages are added to dependencies with patched minimum versions (lodash ^4.18.1, handlebars ^4.7.10, postcss ^8.5.29). The addon doesn't import them directly. A consuming app whose lockfile already pins older copies for other dependents can still keep them. Downstream apps should run yarn upgrade lodash handlebars postcss after picking up 4.10.2.

The ember-cli-htmlbars/semver resolution is removed. It made yarn 1 crash with Invariant Violation: should have a resolved reference, so yarn install failed even on scf_master.

Bug fix: modal footer submit reloaded the page

The modal footer is a <form>. Since f005cd0 its primary button has been type="submit", but nothing called preventDefault() on the form's submit event. Clicking the submit button of a <BsModalSimple @submitTitle=...> therefore called onSubmit and natively submitted the form, which reloads the page. In CI this appeared as an intermittent Browser timeout exceeded: 10s in the bs-modal-simple tests, because the reload killed the test runner.

BsModal::Footer is now a small Glimmer component that prevents the default action before calling @onSubmit. A regression test covers this.

CI fixes (ember-try scenarios)

ember-try installs without the lockfile, so all 36 scenario jobs picked up recent upstream releases that break on our Node 16 / ember-cli 3.28 setup. Both fixes are resolutions only, so they don't affect consumers.

• testem pinned to ~3.18.0: testem 3.19+ uses ESM-only execa, and testem 3.20+ requires Node 20, which caused ERR_REQUIRE_ESM in the 30 non-Embroider scenarios.
• @embroider/addon-shim pinned to 1.10.2: 1.10.3 opts v2 addons (here ember-focus-trap) into per-bundle addon caching. ember-cli 3.28 rejects that when the dummy app sets an addon blacklist, which it does under FASTBOOT_DISABLED. That broke the 6 Embroider scenarios.
• pkg-entry-points pinned to 1.1.1: addon-shim 1.10.2 pulls it in, and 1.1.2 requires Node ≥20.19.5, which would break the Node 16 install.

Moving CI to Node 20+ would let these pins be dropped later.

Testing

• CI is fully green: all 39 jobs, including every ember-try scenario.
• Locally on Node 16 and Node 22: yarn install --frozen-lockfile, yarn lint (0 errors), yarn build, and ember test (526 passed, 10 skipped, 0 failed) all pass. yarn nodetest passed on Node 22.

Follow-up outside this PR

• Rescan with FOSSA and update the linked COMP findings.
• Bump downstream SCF apps to 4.10.2 and refresh their lockfiles (see above).
• yarn audit still reports advisories in other packages, mostly dev tooling (got, form-data, @octokit/*, semver, …). They are out of scope here.

🤖 Generated with Claude Code