Fix @val shadowing (fixes #8093)

Summary

When a @val external is assigned to a local let with the same name (example: "process"), the JS output becomes let process = process; and crashes at runtime. This PR rewrites the initializer to globalThis.process only when a local lexical binding would shadow that global, while leaving all other uses unchanged.

Example:

module X = {
  @val external process: unknown = "process"
}

let process = X.process
let proc = X.process

Output after this change:

let process = globalThis.process;
let proc = process;

Why this approach

• The failure is a JS runtime error caused by shadowing a global with a local let.
• We only need to fix the conflicting initializer. Emitting globalThis everywhere would be noisier and change more output than necessary.
• The rewrite is scoped and conservative: it only applies when a local lexical binding would otherwise read itself.

Why existing name mangling cannot solve it

ReScript’s $1/$2 name mangling only applies to compiler-owned identifiers (Ident.t) that go through Ext_pp_scope. @val externals are emitted as raw JS globals (E.js_global / Ext_ident.create_js) and do not participate in that scope renaming system. That means the compiler cannot “rename” process to process$1 in this case, because the global read is not an Ident.t that the mangler controls. We must explicitly disambiguate the global read instead.

Implementation notes

• Introduce a small JS pass that detects lexical bindings which shadow JS globals and rewrites only those reads to globalThis.<name>.
• Skip JS keywords and JS globals to avoid generating invalid JS (delete) or unnecessary rewrites.

Tests

• Source-level test in tests/tests/src/ExternalShadow.res covers the shadowing case and a non-shadowed alias.