fix: improve error handling in PowerShell guidelines

[time-by-waves]

Update error handling examples to use $PSCmdlet.WriteError() and $PSCmdlet.ThrowTerminatingError() instead of Write-Error and throw for better PowerShell cmdlet integration.

Pull Request Checklist

• I have read and followed the CONTRIBUTING.md guidelines.
• My contribution adds a new instruction, prompt, or chat mode file in the correct directory.
• The file follows the required naming convention.
• The content is clearly structured and follows the example format.
• I have tested my instructions, prompt, or chat mode with GitHub Copilot.
• I have run node update-readme.js and verified that README.md is up to date.

---

Description

Updates the error handling section and examples in the PowerShell cmdlet development guidelines to follow best practices for advanced functions.

Changes:

• Updated error handling guidelines to recommend $PSCmdlet methods over Write-Error and throw in advanced functions
• Added guidance on constructing proper ErrorRecord objects with error IDs, categories, and target objects
• Updated Remove-UserAccount example to demonstrate $PSCmdlet.WriteError() for non-terminating errors and $PSCmdlet.ThrowTerminatingError() for terminating errors
• Updated New-Resource example to use $PSCmdlet.ThrowTerminatingError() with proper ErrorRecord construction

These changes ensure GitHub Copilot generates PowerShell code with better error reporting and integration with PowerShell's error handling pipeline.

---

Type of Contribution

• New instruction file.
• New prompt file.
• New chat mode file.
• Other (please specify): Update to existing instruction file

---

Additional Notes

This update improves the existing PowerShell guidelines (example.md) to align more closely with Microsoft's recommended patterns for advanced function error handling. The use of $PSCmdlet.WriteError() and $PSCmdlet.ThrowTerminatingError() provides better integration with PowerShell's error handling pipeline and allows for more detailed error categorization.

---

By submitting this pull request, I confirm that my contribution abides by the Code of Conduct and will be licensed under the MIT License.

[Copilot]

Pull Request Overview

This PR improves error handling practices in PowerShell cmdlet development guidelines by transitioning from basic PowerShell error handling methods to advanced function-specific approaches using $PSCmdlet methods.

• Updated error handling guidelines to recommend $PSCmdlet.WriteError() and $PSCmdlet.ThrowTerminatingError() over Write-Error and throw
• Enhanced examples with proper ErrorRecord construction including error IDs, categories, and target objects
• Standardized string quotes from double to single quotes throughout examples

[Copilot]

[nitpick] Inconsistent quote style change. The original double quotes were appropriate and follow PowerShell conventions for strings that may contain variables or escape sequences. Consider keeping double quotes for consistency with existing PowerShell practices.

Suggested change

	Write-Verbose 'Starting resource status update process'
	Write-Verbose "Starting resource status update process"

[TMA-2]

No, expandable strings are only necessary when they contain variables or subexpressions. Otherwise, string literals are perfectly fine, and PSSA even has a rule (off by default) to convert any string literals to single quotes: PSAvoidUsingDoubleQuotesForConstantString

[Copilot]

The change from if ($PassThru) to if ($PassThru.IsPresent) is unnecessary. PowerShell switch parameters evaluate to $true when present and $false when absent, making the .IsPresent property redundant in boolean contexts.

Suggested change

	if ($PassThru.IsPresent) {
	if ($PassThru) {

[Copilot]

[nitpick] Good improvement using $PSCmdlet.WriteError() with proper ErrorRecord construction. However, consider using a more specific exception type like [System.ArgumentException] instead of the generic [System.Exception] for better error categorization.

[TMA-2]

Considering it categorizes it as ObjectNotFound, I'd say it's perfectly fine, unless you have a better .NET exception it could use? Perhaps [Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException]?