[Docs] Clarify bounded Fast monitoring

[roomote-community]

​Created by Roomote. View the task or mention @roomote for follow-up asks.

What changed

• document that ongoing-process monitors require a finite run count or end time
• distinguish quiet monitoring checks from reminders that always reply
• clarify monitor stop conditions, bounded completion, and the unbounded schedules that remain available for recurring reminders and reports

Why this change was made

A review of user-facing changes merged during the previous 24 hours found that the Fast Session monitoring guide still described the older, less restrictive wakeup behavior.

Impact

Users now get accurate guidance for scheduling ongoing checks, choosing finite bounds, and understanding when monitoring stops. This is a documentation-only change.

[roomote-community]

1 issue outstanding. See task

• apps/docs/fast-sessions.mdx:161 Clarify that one-shot monitors are inherently bounded; recurring ongoing-process monitors require x<count> or until.

_{Reviewed 1db8895}

[roomote-community]

This rule also applies to the one-shot monitoring checks described just above, but a one-shot schedule cannot carry x<count> or until: the parser returns maxRuns and until as null for in ... / at ... schedules. That makes a valid finite one-shot monitor (for example, “check CI in 20m”) appear unsupported. Limit the new requirement to recurring ongoing-process monitors, or state that one-shot checks are inherently bounded.