Verify delegation-slot materialization compatibility #151

Scope

MBV's delegation-slot fix separates a delegated account's stored stamp from the source snapshots used for freshness and action dependencies. The Engine-backed port needs the same stale-data rejection and activation behavior without weakening lifecycle ordering.

The source implementation already raises the delegated stamp over a plain local copy when the source data is at least as fresh. For example, delegation slot 90, local read-only slot 100, and source-data slot 110 produce a stored stamp of 100, not a slot regression. A newer companion view alone must not authorize replacing newer base-account data.

Check this contract against Engine 0.9.0's lifecycle table and account materialization ownership. The existing table permits equal-slot ReadOnly/Placeholder-to-Delegated activation, but requires a strictly newer slot for Transient-to-Delegated redelegation. Preserve the contract established by #134; do not simulate an intermediate mode or permit arbitrary slot regression.

Outcome

• Document and verify the compatible materialization contract for delegation stamps, source-data freshness, and companion/dependency freshness. Keep chain confirmation and token-specific policy in MBV.
• Verify stale-source rejection, same-slot activation from a plain account, repeated observations without action replay, strictly newer redelegation, and cancellation/reacquisition before fallback.
• Exercise the slot-90/100/110 example and the case where only the companion view is newer than the local base-account data.
• If the existing Engine API suffices, record that result without changing runtime policy. If an API change is necessary, specify its narrow authorization and compatibility requirements before implementation.

This is separate from #150's new MagicATA account mode; no Engine defect or missing slot-regression permission is assumed.