fix(purchase): route Azure Redis purchases to managedredis before the go pin includes go#694 #1801

LeanerCloud/cloud-commitments-go#694 makes the Azure cache client refuse every purchase (it wraps common.ErrRefusedBeforePurchase, and nothing is sent). managedredis (common.ServiceMemoryDB) becomes the only Azure service that buys RedisCache reservations, so one Redis recommendation can't be bought twice (go#538).

Platform still routes Azure Redis purchases to the cache client:

• internal/purchase/execution.go:1317: mapServiceSlug maps the cache slug to common.ServiceCache, with no provider-specific case.
• execution.go:1157-1160: the purchase path calls cloudProvider.GetServiceClient(recCtx, serviceType, rec.Region) with that service type.

Once a go pin bump includes go#694, every Azure Redis purchase through platform is refused instead of bought.

Fix: where the purchase picks its service client (execution.go:1157; rec.Provider is known there), route Azure ServiceCache to common.ServiceMemoryDB, so the managedredis client buys it. Leave AWS cache and ElastiCache unchanged. Check whether managedredis reads Recommendation.Service, and set it to match the client. The history and suppression service labels shouldn't change unless a reader depends on them; check partition_guard.go:26 and the :1058 history-record path.

Tests:

• An Azure cache recommendation reaches the ServiceMemoryDB client. It should fail first against today's routing, with a fake provider recording the requested service type.
• An AWS cache recommendation still reaches ServiceCache or ElastiCache.

Coupling: this must land in the same PR as the go pin bump that includes go#694, the same way #1789 rides with the bump that includes go#688. Azure deploys are paused, but the purchase path ships with the code.