MS-311/feat(cart): shipping price support with proportional promo discount distribution

Summary

This MR introduces shipping price as a first-class field on the cart. It covers the full vertical slice: domain model → DTO → mapper → service logic → API endpoint.

What changed

Data model & DTO Two new fields are introduced on the cart DTO: the raw shipping price set by the caller, and the shipping price after any promo code discounts have been applied. Both are returned in every cart response so the frontend can render a clear price breakdown.

Promo code distribution Previously, cart-level and percentage discounts were distributed across eligible items only. They now include the shipping fee in the base total. The discount is split proportionally: each item absorbs a share relative to its price, and the shipping fee absorbs its own share. The items-only total is kept separate so downstream discount fields remain accurate.

Promo code validation Minimum amount thresholds and the "does this code actually reduce the total" guard both now count shipping in the reference total, preventing edge cases where a code appeared valid on product subtotal alone but had no real effect once shipping was included.

New endpoint PUT /{clientId}/shipping?shippingPrice=… persists the shipping price and returns a reloaded cart.

Reload refactor The no-save reload path now delegates to a single parameterised implementation, removing duplicated logic between the two variants.

Testing notes

• Verify promo code discount is correctly split between items and shipping for all three promo types.
• Verify shippingPriceAfterDiscount is lower than shippingPrice when a cart-level or percentage code applies.
• Verify shippingPrice is preserved as the original value in the response even after discounts.
• Verify the new endpoint persists and reloads correctly.
• Verify no-save reload returns the correct shipping breakdown without writing to the database.