docs: clarify continue-as-new behavior for child workflows #5021

[Pittu-Sharma]

Description

This PR addresses issue #5021 by explicitly clarifying the behavior of the continue-as-new API regarding unawaited child workflows. This is a critical detail for developers implementing the Monitor Pattern, as continue-as-new proceeds immediately and does not wait for child workflows started via CallChildWorkflowAsync (or equivalent SDK methods) unless they are explicitly awaited.

Key Changes:

• Clarification Notes: Added standard {{% alert %}} boxes to the Monitor pattern section in workflow-patterns.md and the Infinite loops section in workflow-features-concepts.md.
• Documentation Polish: Refined code comments across modified blocks to ensure "logical completeness." Generic placeholders (e.g., // Do some work) have been replaced with descriptive, professional business logic markers (e.g., // Initial business logic (e.g., inventory check)).
• Quality Fixes: Corrected minor technical debt, including comment style mismatches (Python # in JS blocks) and typos ("cancled" to "cancelled").

Issue reference

Closes #5021

[nelson-parente]

Pre-review for @marcduiker handoff: LGTM with nits.

• The continue-as-new alert boxes are a useful clarification for the monitor pattern and infinite loop sections.
• Comment improvements (replacing generic placeholders with business-logic descriptions) are a nice polish.
• The maintainer-guide.md changes (azd auth login, remove stale SDK doc pull section) overlap with #5083 and #5101 from the same author — Marc, one of these three PRs has the maintainer-guide fix and all appear to land the same change. Confirm only one gets merged to avoid conflicts.
• Nit: the Python comment fix from # Apply some compensating work to # Add logic here to undo partial changes accidentally appears under a JS code block (// Add logic here...) — the JS block fix looks correct; the Python snippet looks fine too.
  Nothing blocking — Marc, your call.