Summary

MapFromServiceLocator can now ask the service locator for a view under a contract, so a contracted IViewFor<T> registration is reachable.

• New overload MapFromServiceLocator<TViewModel, TView>(contract, serviceContract). The mapping resolves under contract, and asks the service locator for TView under serviceContract. A view not registered under that contract throws InvalidOperationException naming the contract.
• The existing overloads keep their behaviour. MapFromServiceLocator<TViewModel, TView>(contract) still asks the service locator with no contract; its docs now point at the new overload.
• New example MapContractedViewFromServiceLocator registers a default and a contracted IViewFor<TodoItem> in the service locator and maps each.

Why

A view model with a default view and a contracted view, both registered in the service locator as IViewFor<T>, could not be mapped by contract: MapFromServiceLocator<T, IViewFor<T>>(contract) always returned the default registration. Passing the mapping's contract through would break code that maps a concrete view, registered with no contract, under a contract, so the service contract is a separate argument.

Breaking changes

None. The change adds an overload.

How this was verified

• Runtime tests cover a default and a contracted IViewFor<T> registration mapped side by side, and the error for a missing contracted registration.
• Ran the Linux examples suite and the Windows examples on a real Windows machine; the new example prints what its comments say.

Notes for the reviewer

• Start with ViewMappingBuilder.MapFromServiceLocator<TViewModel, TView>(string?, string?).
• Mechanical: the PublicAPI baseline entries for the new overload in both runtime leaves.

Checklist

• I have read the Contribute guide
• The PR title follows Conventional Commits
• Tests cover this change, or the summary says why they do not
• New or changed public API has XML documentation