app_record: Fix hangup handling during beep and before record loop

[UpBeta]

Summary

When a hangup occurs while app_record is playing the initial beep (or immediately after it), but before entering the main recording loop, the application does not detect the hangup and continues running until the maxduration timeout expires.

Changes

This change properly handles hangup in two places:

1. After ast_waitstream() returns -1 during beep playback, indicating that the channel was hung up while the beep was playing. Also checks for hangup when ast_streamfile() itself fails, as this may also be caused by a hangup condition.

2. Safety net before the recording loop: checks ast_check_hangup() before entering the ast_waitfor() loop. This covers the case where hangup arrives after the beep completes (or when using the quiet option) but before frames are read.

This ensures the application exits immediately with RECORD_STATUS set to HANGUP rather than waiting for the full timeout duration.

Approach

This is an improved fix over PR asterisk#1790 by silverjoe. As suggested by InterLinked1 in that PR review, this version handles the failure of ast_streamfile/ast_waitstream directly at the source, rather than relying solely on an explicit hangup check. The safety-net check before the loop is retained for edge cases (e.g., the q option where no beep is played).

Testing

• Verified correct brace balancing and code structure
• The fix follows the existing patterns in app_record.c for hangup detection and goto out cleanup

cherry-pick-to: 22
cherry-pick-to: 23
cherry-pick-to: 20