Audit Remove-* functions for pipeline-safe error handling #572

Context

While fixing #571, it was discovered that Remove-GitHubWorkflowRun calls Invoke-GitHubAPI without error handling. Since Invoke-GitHubAPI calls $PSCmdlet.ThrowTerminatingError() on API failures, a single failed deletion kills the entire pipeline — preventing all subsequent items from being processed.

This pattern likely exists in other Remove-* functions (and potentially Set-*, Add-*, and other data-modifying functions that support pipeline input).

Request

Audit all functions that:

1. Accept pipeline input (ValueFromPipeline or ValueFromPipelineByPropertyName)
2. Call Invoke-GitHubAPI in their process block

For each such function, wrap the Invoke-GitHubAPI call in a try/catch that writes a non-terminating error (Write-Error) instead of allowing the terminating error to propagate. This ensures that:

• One failed API call does not kill the pipeline
• The error is still surfaced to the user with context (e.g., the item ID)
• Remaining pipeline items continue processing

Example pattern

# Before (pipeline-killing)
$null = Invoke-GitHubAPI @apiParams

# After (pipeline-safe)
try {
    $null = Invoke-GitHubAPI @apiParams
    Write-Verbose "Deleted resource [$ID] in [$Owner/$Repository]"
} catch {
    Write-Error "Failed to delete resource [$ID] in [$Owner/$Repository]: $_"
}

Acceptance criteria

• All Remove-* functions that accept pipeline input use try/catch around Invoke-GitHubAPI
• Error messages include enough context to identify which item failed (e.g., ID, Owner, Repository)
• A single API failure does not terminate the pipeline for remaining items
• Set-* and Add-* functions with pipeline input are also reviewed for the same pattern