Validate program upgrades during execution and cloning

[bmuddha]

Outcome

An upgrade must not cause MBV to execute an inconsistent combination of program metadata and executable bytes, or continue using an obsolete executable after fresh materialization is established.

Existing loader tests verify supported formats, not an upgrade occurring while the program is in use.

Scope

Provide two versions of a fixture program with clearly different observable effects. Continuously invoke version A, upgrade it to version B on base, and delay MBV’s program/programdata fetch responses or notifications.

During the delay, issue further invocations and cold-clone requests. Then release fresh observations and verify convergence to version B.

Keep this on the supported upgrade path; do not assume every ER execution switches at the exact instant the base upgrade lands.

Acceptance criteria

• Every successful invocation has a valid A or B effect, never a mixed or malformed result.
• Loading and execution failures leave no partial program-state changes.
• Once fresh materialization is established, subsequent invocations consistently execute B.
• Reports identify the base upgrade transaction, held observations, observed versions, and convergence point.