Add explicit module replacement for tests

Summary

Add a project-native testing API for explicitly replacing imported modules and restoring module state during tests.

Why

Function mocks and spies cannot isolate code whose dependency is captured through an ES module import. Tests need a controlled loader-level replacement mechanism that preserves GocciaScript's sandbox and module semantics.

Current behavior

The testing runtime provides mock() and spyOn() for callable values. TGocciaModuleLoader owns resolved-module caches and host-configured virtual modules, but the testing library has no per-test replacement, reset, or restore surface.

Expected behavior

• Allow tests to register an explicit replacement module or replacement factory before that module is evaluated.
• Resolve replacement specifiers through the same aliases, import maps, and canonical identities as normal imports.
• Define cache behavior and ES module live-binding behavior for replaced exports.
• Restore or reset replacements reliably between test files and at the requested test/suite boundary.
• Keep replacement state isolated across serial and --jobs runs and equivalent across interpreter/bytecode modes.
• Provide diagnostics for late, conflicting, or unresolved replacements.

Scope notes

• Prefer an explicit API that fits the existing testing runtime; do not require a vi.* namespace.
• Transform-hoisted static-import mocking, automatic deep mocking, Vite transform behavior, CommonJS, and Node/npm module resolution are out of scope.
• Host-configured virtual modules remain an embedding capability rather than becoming ambient test authority.
• Related #119 implemented function-level mock/spy infrastructure, not module replacement; #114 is the closed parent API issue.

Start by reading TGocciaModuleLoader and the existing testing runtime APIs, including mock() and spyOn(), to understand module caches, virtual modules, and test boundaries. Define the replacement, reset, restore, isolation, and diagnostic behavior within the stated scope, then verify it across serial and --jobs runs and interpreter/bytecode modes.