Fix atlascloud universe concierge buyer notification recipient

[asim]

Root cause:

• CI run https://github.com/micro/go-micro/actions/runs/28645508619 failed only in the Harness (E2E) workflow's Provider harnesses (live LLM conformance) job on master at c645c5faa7c0f6be53e7643db00451fed5349659; the mock harness job passed.
• The live run configured only atlascloud (ATLASCLOUD_MODEL=minimaxai/minimax-m3); anthropic/openai/gemini/groq/mistral/together were skipped because their API keys were unset.
• atlascloud passed agent, agent-flow, and a2a-stream-fallback, but failed universe and plan-delegate.
• In internal/harness/universe, the checkout flow recovered from the intentional payment failure and resumed correctly through inventory, charge, and order confirmation. The failure happened at the concierge notification step: the notify service logged ignored non-buyer notification to=buyer-of-order-1 "Your order order-1 has been confirmed. Thank you for your purchase!", so the buyer notification count remained zero.
• Because the notify step returned concierge completed without notifying buyer: notify count stayed at 0, the resumed flow stayed pending and the final persisted flow assertions failed (no pending runs and flow run ... marked done). This is a harness/code conformance defect in the concierge -> notify argument/recipient path, not a provider outage, rate limit, or network timeout.

Where:

• internal/harness/universe checkout/concierge notify path and buyer-recipient validation.
• Live conformance run: https://github.com/micro/go-micro/actions/runs/28645508619

Acceptance criteria:

• The atlascloud/minimax universe harness reliably resumes checkout after the intentional payment retry and sends exactly one accepted buyer notification through the concierge agent.
• The notify recipient accepted by the harness matches the expected buyer identity for the order; attempts with malformed/non-buyer recipients remain rejected.
• A failed concierge notify must leave actionable diagnostics showing the expected recipient and actual tool arguments.
• Add or update deterministic coverage around the resumed checkout notify step so a completed agent wrapper call cannot be mistaken for a successful buyer notification when the notify service rejects the recipient.
• A follow-up Harness (E2E) provider-conformance run passes atlascloud / universe and leaves no pending checkout flow run.