The new test cases use [fullhash] / [fullhash:8] / pathData.hash in
publicPath, so the snapshot includes the actual compilation hash. On
Windows checkouts the .js fixtures (index.js, webpack.config.js,
test.config.js) were converted to CRLF by the text=auto baseline,
which changed the bundled JS module content and therefore the
compilation hash, causing snapshot mismatches in CI.

Pin those .js files to LF so the snapshot is platform-stable.

…or message

When a runtime module's generate() / getGeneratedCode() returns null
(e.g. CssLoadingRuntimeModule when the chunk needs no loading or HMR),
RuntimeModule.updateHash was passing null to hash.update(), which
threw a TypeError that the surrounding try/catch then hashed via
err.message. Node 14 and earlier produce
  "Cannot read property 'length' of null"
while Node 16+ produce
  "Cannot read properties of null (reading 'length')"
so the same compilation produced different fullhashes on different
Node versions. With the actual hash now appearing in CSS url()
references that resolve [hash]/[fullhash] in publicPath, this
surfaced as snapshot mismatches on the Node 10/12/14 CI legs.

Skip hash.update when the generated code is null/undefined so the
runtime module hash reflects an empty contribution rather than a
JavaScript error string. Updates the public-path snapshots to the
new (now Node-stable) hash.