Fix concurrency races on shared std module and MemberList caches (#1047)

[stephenamar-db]

When independent Interpreters run concurrently (e.g. a Bazel bundle worker fanning evaluation across a thread pool) they share the process-wide default std module and, via the parse cache, the StaticOptimizer-folded AST. Two pieces of shared mutable state raced:

1. The default std module is a singleton built with static = false, so the first std.foo lookup (which StaticOptimizer triggers while folding) called putCache, mutating the inline cache (ck1/cv1) and lazily allocating the valueCache HashMap. Concurrent first access could return the wrong builtin or corrupt the map. Add Val.Obj.mkWithConstCache, which pre-fills the value cache for every constant field at construction; StdLibModule.module now uses it, making lookups read-only. Context-dependent members (thisFile/pi) carry cached = false and never write either, so the instance is immutable after construction.

2. Expr.ObjBody.MemberList._cachedAllKeyNames / _cachedVisibleKeyNames are shared across interpreters via the parse cache but were non-volatile; an unsafe publication could expose a half-filled array. Make both @volatile, matching the existing _cachedSortedOrder / _noSelfRef pattern.

Adds regression tests to ParallelManifestRaceTests: a deterministic guard that the std value cache is pre-filled at construction, plus concurrent stress tests for std first-access and shared-MemberList materialization. Also fixes the test file to use java.lang.AssertionError (utest._ shadows it).

This builds on #1050 (renderer scratch buffers) and the static-object sorted-key cache fix, which together cover the data races in #1047 that are reachable under the supported concurrency model (independent interpreters).

[stephenamar-db]

@He-Pin