Add analyses error detection to the weekly code scanning workflow

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 #1495 (merged) and parent issue #1329

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