docs: make customer onboarding and monitoring actionable

[Hou (SciencePotato)]

Summary

Make the customer documentation a coherent path from prerequisites and configuration values through deployment, provider authorization, validation, activation, and ongoing operations.

• Add the Microsoft Security Store link and explain eligibility, ownership, and assisted onboarding gates.
• Document where each customer value comes from, where it is set, and which settings guided setup already configures; distinguish tenant/client/object/provider/managed-identity IDs and the separate trust paths.
• Separate guided customer deployment from optional local development/manual publishing, clarify supported providers and Global/EU semantics, and warn about reconfiguring existing deployments with the same prefix.
• Add actionable Telesign secret-entry and Soprano provider-admin handoffs, safe acceptance checks, deployment-summary guidance, a complete noninteractive example, and explicit activation/rollback boundaries.
• Extend the existing Application Insights and monitoring guides with runtime-specific log discovery, alert/notification ownership, certificate-expiry operations, cost/retention considerations, and troubleshooting.
• Correct stale cross-runtime credential-refresh, logging, and voice-behavior claims against the checked-in implementation.

Scope and verification

Documentation-only: 11 Markdown files changed, based on current upstream main at the time of implementation. Existing monitoring documentation is reused; runtime, infrastructure, and other open PR branches are unchanged.

The resulting customer flow and runtime-specific guidance were inspected against the setup/runtime source. git diff --check passes. No Azure resources were deployed, policies changed, credentials provisioned, or live SMS/voice calls sent for this documentation change.

Explicit external prerequisites

Microsoft-approved EPP testing/activation and Soprano provider-side authorization remain assisted steps. Public Graph SMS/Voice resource definitions do not document EPP url/appId fields, so this PR does not invent a PATCH contract or suggest bypassing caller authentication. Monitoring examples require customer-side schema/collection verification and alert configuration; setup alone does not create those alerts.