arch: type environment markers before marker set grows

[dowdiness]

Context

PR #438 moves interpreter-only scope metadata out of Environment.bindings into Environment.markers, closing the main fake-binding risk from #437. The new representation is still intentionally simple: markers : Map[String, Bool] plus helper functions in interpreter/runtime/environment.mbt.

This is acceptable while the marker set is small, but it leaves the same kind of string-key typo/proliferation risk tracked for other runtime metadata in #360.

Problem

If environment markers keep growing, free-form string keys make it easy to add another marker convention without a central type-level inventory. That can reintroduce cognitive overhead and review risk: contributors must know which strings are valid, which markers are fixed versus per-binding, and which lookup helper is appropriate.

Suggested work

When a fourth environment marker is needed, or if marker call sites start to spread, replace the stringly marker API with a typed marker representation, such as:

• an EnvironmentMarker enum with variants for fixed markers and payload-bearing eval-created variable markers, or
• an opaque helper API that keeps all string construction private to environment.mbt.

Keep the implementation scoped to interpreter/runtime/ and preserve PR #438 behavior.

Acceptance criteria

• Valid environment marker kinds are discoverable from one type or one private helper section in environment.mbt.
• Call sites do not pass ad-hoc marker strings to set_marker / has_marker / has_marker_in_chain.
• Eval-created deletable-var markers still support per-binding names without colliding with fixed markers.
• No behavior change: moon check && moon test passes.
• Delete-focused Test262 baseline remains unchanged: make test262-filter FILTER="delete" reports the same Passed / Executed and Passed / Discovered counts as before the refactor.