Default applications.moduleLoader to vm-current-context

[kriszyp]

Summary

Update the harper-pro shipped default applications.moduleLoader from vm to vm-current-context in static/defaultConfig.yaml, matching the core change in HarperFast/harper#1248.

Purpose

vm-current-context runs the application VM loader in Harper's own context so applications share JavaScript intrinsics, avoiding cross-realm instanceof/identity-check failures at the application/Harper boundary. vm mode (separate intrinsics) remains available for anyone who needs it.

Where to look

• Config-only change; the behavioral implementation lives in core (#1248).
• This PR intentionally does not bump the core submodule pointer — the core default flip lands via #1248 against core main first.

Generated with assistance from Claude (Opus 4.7); reviewed by Kris.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[claude]

Reviewed; one potential blocker found.

Correctness: vm-current-context may not be supported by the currently pinned core commit

static/defaultConfig.yaml now advertises moduleLoader: vm-current-context as the default, but the core submodule pointer is unchanged at 3025d37. If that core commit does not recognize vm-current-context, new installs using this config template will either fail to start or silently fall back to vm — the opposite of the intended change.

The PR body states "the core default flip lands via #1248 against core main first", but no submodule bump is included here. This PR should not merge until a companion commit bumps the core submodule pointer to a commit that includes vm-current-context support, or alternatively the submodule bump should be added to this PR.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!