fix(eve): resolve code-defined model imported from a sibling module in dev

[dang-w]

Fixes #92.

Problem

eve dev (and therefore eve eval, which runs through the dev runtime) fails at turn
time with LoadCompiledModuleMapError when an agent's model is a code-defined provider
object (e.g. anthropic("claude-opus-4-8")) imported into the agent config from a
sibling module:

LoadCompiledModuleMapError: Cannot find module '.../source/agent/lib/models.js'
  imported from '.../source/agent/agent.ts'

eve build + eve start resolve the same agent fine; only the dev runtime is affected.

Root cause

A non-string model can't be serialised into durable state, so it becomes a source-backed
model reference that is re-imported at turn time to read .model back out
(resolve-model.ts → loadSourceBackedRuntimeModelReference). That path called the basic
loadCompiledModuleMap directly, which imports module-map.mjs and re-imports the
authored config from raw .ts source — without the NodeNext .js→.ts specifier mapping.

Meanwhile the normal agent-loading path (compiled-agent-cache.ts) already branches on
moduleMapLoaderPath and uses the authored-source loader (loadAuthoredModuleNamespace)
in dev, which resolves those specifiers correctly. The two paths diverged; the model
resolver used the wrong one.

Fix

Extract that branching logic into a single shared loadRuntimeCompiledModuleMap in
runtime/loaders/module-map.ts, and route both the compiled-agent cache and source-backed
model resolution through it. So a code-defined model imported from a sibling module now
resolves identically in dev and production. Net change is a small consolidation
(+49/−39) that removes the duplicated loader.

Verification

• Repro fixed end-to-end. A fresh eve init app with export const model = anthropic("claude-opus-4-8") in agent/lib/models.ts, imported by agent/agent.ts, fails
  on eve eval before this change. After it, model resolution succeeds and the run proceeds to
  the actual model call (no more LoadCompiledModuleMapError).
• Regression test added (runtime/agent/resolve-model.test.ts): asserts source-backed
  model resolution loads the module map through loadRuntimeCompiledModuleMap (the
  authored-source-aware loader), not loadCompiledModuleMap. It fails on the previous code and
  passes on the fix. (A note on why it's a unit test: the runtime failure only reproduces under
  real Node — vitest's loader transparently remaps .js→.ts, so an end-to-end scenario test
  passes either way and can't guard this regression. The unit test pins the loader the resolver
  must use.)
• No regressions. typecheck, build, and the existing scenario + integration tests for
  the authored-source loading path (authored-module-loader.scenario, cache-key.scenario,
  dev-runtime-artifacts.integration) all pass.
• Changeset included (patch).

[vercel]

@dang-w is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.