docs: simplify the customer setup walkthrough

[Hou (SciencePotato)]

Summary

Simplify customer onboarding into five clear steps: get ready, register the application, run guided setup, connect/test the provider, and activate/hand over.

• Keep the main README provider-neutral, using plain language and links to exact provider instructions rather than named-provider details.
• Simplify navigation and phrasing across setup, configuration, monitoring, Application Insights, troubleshooting, and the developer fallback guide.
• Keep the architecture image and deeper technical requirements in the technical reference.
• Preserve permission, billing, authentication, validation, and assisted activation boundaries.
• Add five real Azure portal screenshots using a standalone Edge browser controlled by Playwright, rather than the shared browser.
• Run the real setup script and add two redacted terminal captures covering identifiers, region, channel, provider route, language, and hosting-plan choices.
• Explain that there is no -DryRun or -WhatIf: a real preflight followed by No/Enter at the approval gate is a cancellation, not an offline simulation.
• Add cropped real Security Store provider-card examples and illustrated Key Vault credential-entry steps. Keep the main prose provider-neutral; label the named offer cards as examples, not endorsements or setup-support guarantees.
• Refine the illustrations: crop repeated terminal output, point arrows at redacted monitoring links, and move named Security Store cards to the detailed guide so the main README is visually provider-neutral.
• Add a redacted app Overview with client/tenant ID callouts and Object ID marked "DO NOT USE" for setup inputs.
• Add a real Logs KQL query and safe aggregate results in the monitoring guide, with stored-row and delivery caveats.

Screenshots

• App registration form: single-directory account type and blank redirect URI.
• Existing regional resource group: example resource types created by setup, not manual creation instructions.
• Function Authentication: Enabled, Require authentication, and HTTP 401 for unauthenticated requests.
• Function Monitoring navigation: linked Application Insights resource.
• Application Insights Overview: linked Logs workspace.
• Actual script identifier/region/channel input screen.
• Actual script provider/language/hosting-plan choices and cost warning.
• Security Store sample provider cards, excluding account controls and unrelated offers.
• Key Vault > Objects > Secrets, showing secret names/status only.
• Generate/Import > Create a secret, with an unsaved fake masked value.
• App registration Overview: identify Application (client) ID and Directory (tenant) ID, not Object ID.
• Logs query and aggregate result: KQL mode, Run, and Results shown without sensitive payloads.
• Actual complete deployment-plan/approval screen: deferred by the owner; sample pictures are sufficient.
• Actual deployment progress and completion summary: deferred by the owner; not claimed as completed.

Account details, tenant names, resource names, identifiers, instrumentation keys, and connection information were cropped or permanently covered in the PNG pixels. Each final image was visually inspected. The registration form uses an example name and was not submitted. Other screens show an existing nonproduction deployment; captions explain their limits.

The screenshots are illustrative navigation aids, not evidence of a new deployment, successful activation, or recipient delivery. The Microsoft identity provider shown under Authentication is explicitly distinguished from the selected phone provider.

Actual script walkthrough status

A new dedicated nonproduction app registration was created, and the unmodified public setup script was run at source revision 48b94a3d42e74ef2a1a65a286a7f8e24a53353ff. Its real PowerShell process was displayed in a private local terminal viewer; screenshots do not contain simulated script responses.

The initial GitHub public API call hit a shared-IP rate limit. Authenticated GitHub metadata access was used for the reviewed pinned source without changing setup logic. The run then collected the actual inputs and reached prerequisite checks, but stopped because the required tenant-specific Microsoft Graph delegated context was not established.

The approval prompt was not reached. No Azure hosting resources were deployed, no policy was activated, and no provider messages were sent. The existing-resource portal images are not substituted for a completed setup run. The owner subsequently clarified that sample pictures are sufficient; the remaining live deployment captures are deferred.

The Key Vault example form uses example-provider-api-key and a fake masked value, then was cancelled. No secret was created, revealed, or changed for these screenshots. Captions direct readers to the exact provider-specific names and their own setup-created vault. OAuth onboarding remains a separate administrator handoff.

Verification

• Earlier draft review: 13 documentation files reviewed/rendered, 357 links/images checked, 38 external URLs returned HTTP 200, and 14 PowerShell, 6 JSON, and 4 JavaScript example blocks parsed.
• Portal and script screenshots visually inspected after opaque redaction; the illustrated README renders all five of its images, with two more in monitoring.
• 303 local Markdown file/image references resolve; git diff --check passes.
• The README renders six images, the monitoring guide renders three, and the detailed onboarding guide renders three. Named provider cards are absent from the README. Final images were visually inspected for identifying information.
• The read-only Logs query returned one aggregate row: HTTP 200, Success=true, StoredRows=11 for the scoped existing test application in the selected 48-hour window. This is not proof of handset delivery or a new deployment.
• The pre-existing local README table-formatting edit was preserved and excluded from the screenshot commit.

Repository changes remain documentation/images only. The dedicated app registration is the only new directory resource from the script walkthrough; the deployment stage did not run.

Draft status

The owner has deferred full live-deployment captures in favor of sample pictures. Requested sample images are now included. Keeping the PR in draft for editorial review; no claim of successful end-to-end deployment or activation is made.