Restore name-availability error enrichment and null-result guard

[Francisco-Gamino]

Summary

Follow-up to #29691. Restores the Reason/Message error enrichment on the
NameAvailable=false path in ValidateFunctionAppNameAvailability that was
inadvertently removed when reverting #29687, and adds a null-result guard for
Test-AzNameAvailability.

Changes

src/Functions/Functions.Autorest/custom/HelperFunctions.ps1:

1. New null-result guard — surfaces a clear FunctionAppNameAvailabilityCheckFailed
   error if Test-AzNameAvailability returns $null (e.g., REST 204 / empty body)
   instead of silently NRE-ing on $result.NameAvailable.
2. Restored Reason/Message enrichment — when the service rejects a name,
   the error message now again includes the service's reason text so users can
   distinguish "already taken" from "invalid characters", etc.

What this does NOT reintroduce

--ErrorVariable nameCheckError -ErrorAction SilentlyContinue on the
Test-AzNameAvailability call — that splatting interaction with
@PSBoundParameters was the actual root cause of the PS 5.1 break in #29687.

• The Write-Warning diagnostic block from Add diagnostics to ValidateFunctionAppNameAvailability for PS 5.1 debugging #29687.

Risk

Very low. Purely additive. No change to the existing happy path. Existing
failure path keeps the same error ID (FunctionAppNameIsNotAvailable),
exception type, and category — only the message gets richer when the service
provides a reason. No AutoRest regeneration required (custom/ only).

Testing

• PS 5.1 and PS 7.x manual New-AzFunctionApp with a taken name → enriched error
• PS 5.1 and PS 7.x manual New-AzFunctionApp with an available name → succeeds
• Empty/null name → unchanged (FunctionAppNameIsNullOrEmpty)

Description

Mandatory Checklist

• Please choose the target release of Azure PowerShell. (⚠️Target release is a different concept from API readiness. Please click below links for details.)

  • General release
  • Public preview
  • Private preview
  • Engineering build
  • No need for a release

• Check this box to confirm: I have read the Submitting Changes section of CONTRIBUTING.md and reviewed the following information:

• SHOULD update ChangeLog.md file(s) appropriately
  • Update src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md.
    • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header in the past tense.
  • Should not change ChangeLog.md if no new release is required, such as fixing test case only.
• SHOULD regenerate markdown help files if there is cmdlet API change. Instruction
• SHOULD have proper test coverage for changes in pull request.
• SHOULD NOT adjust version of module manually in pull request

[azure-client-tools-bot-prd]

Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status.

[thomas-temby]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).