Move MuSig offer construction out of the create-offer review controller

MuSigCreateOfferReviewController.initialize() still assembles the offer payload in the desktop layer: it derives the salted account ids and payload hashes, builds the AccountOption and CollateralOption entries, maps the display direction to the offer direction and only then hands the parts to MuSigService.createAndGetMuSigOffer. The 25% security deposit comes from the review model, so a domain value is sourced from the UI. None of that construction has a domain unit test, because none of it lives in the domain.

The take side already has the right shape: TakeOfferUseCase.getHandoff() returns a record the controller passes to the service. Mirror it here: a CreateOfferUseCase handoff that returns the offer id, offer direction, specs, payment methods and fully built options, with the deposit percentage as a domain constant, and unit tests for the salted id and hash construction. The controller then only displays and publishes.

MuSig is dev-gated, so this is not user-reachable yet.

Part of #4883.

Start with MuSigCreateOfferReviewController.initialize() and compare its responsibilities with TakeOfferUseCase.getHandoff(). Define the CreateOfferUseCase handoff and move offer construction there, including the domain deposit constant; then add unit tests covering salted account IDs and payload hashes and verify the controller only displays and publishes.

Written by the indexing model from the issue text.