Add analyses error detection to the weekly code scanning workflow

[rezatnoMsirhC]

The weekly code scanning workflow (weekly-gh-code-scanning.yml) surfaces open alert findings via /code-scanning/alerts but silently misses SARIF upload failures and CodeQL runner errors. These errors are only visible via the /code-scanning/analyses endpoint's error field. A Check for scan analysis errors step was drafted during PR #1495 but deferred due to unresolved design questions around time-windowing, deduplication, skill ownership, and response scope.

Acceptance Criteria

• Analyses query applies a time-window filter so only errors from the current run window are evaluated, preventing perpetual re-triggering from historical failures
• Deduplication logic prevents creating a new tracking issue when an open error-tracking issue already exists for the same repository
• Design decision recorded: analyses error detection is added as a -IncludeAnalysisErrors switch to Get-CodeScanningAlerts.ps1 or implemented as workflow-only inline logic
• Design decision recorded: SARIF upload failures produce a workflow annotation, a new GitHub issue, or both
• The chosen implementation raises an actionable signal when analyses contain errors
• At least one test or workflow run validates the error detection path end-to-end

Open questions / risks / dependencies

• Should analyses error detection belong to the gh-code-scanning skill (Get-CodeScanningAlerts.ps1) via a new parameter, or remain workflow-only inline logic?
• Is automated issue creation the right response to a SARIF upload failure, or should a workflow annotation suffice?
• Depends on PR feat(workflows): add weekly GitHub code scanning automation #1495 (merged) and parent issue feat(ci): Create weekly code scanning workflows for automated backlog issue creation #1329

Evidence source: stakeholder input — deferred from PR #1495 review; requirement is unvalidated beyond the originating PR discussion.