fix: normalize stuck queue cutoff to UTC

[Chris0Jeky]

Summary

• Normalize the GetStuckProcessingNonCaptureAsync cutoff with ToUniversalTime() before binding it.
• Use the normalized instant in both the SQLite raw-SQL branch and the non-SQLite predicate branch.
• Add a SQLite integration regression with a +02:00 cutoff that distinguishes an actually stale row from a newer row whose textual timestamp would sort incorrectly under the old behavior.
• No stored timestamps, inequality, ordering, limit, or other repository sites were changed.

Verification

• Baseline new regression before the production fix: failed as expected because the old code returned the newer row too.
• dotnet test backend/tests/Taskdeck.Api.Tests/Taskdeck.Api.Tests.csproj --filter FullyQualifiedName~LlmQueueRepositoryIntegrationTests.GetStuckProcessingNonCaptureAsync_WithNonUtcThreshold_ComparesByInstant --no-restore — 1 passed.
• dotnet test backend/tests/Taskdeck.Api.Tests/Taskdeck.Api.Tests.csproj --filter FullyQualifiedName~LlmQueueRepositoryIntegrationTests --no-restore — 43 passed.
• git diff --check — passed.

Two coordinator review passes found no correctness, scope, or test-hygiene blockers. The hosted automatic Codex review was unavailable because the account had reached its code-review usage limit; no merge is being requested here.

The test build emitted existing nullable warnings in unrelated test helpers; no new warning was introduced by this change.

Refs #1422

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Chris0Jeky]

Review gate (Codex review credits exhausted, SC-9; D-12 ruled 2026-09-05: the Codex session's PRs are reviewed and merged by the coordinator): one fresh-context read-only reviewer (Opus 5) on head 6a700c5e1. Verdict: SHIP.

Checked by reading: UpdatedAt has no value converter and the context has no SaveChanges stamping, so EF's default DateTimeOffset to TEXT mapping preserves the offset (the property the shipped #1403 fixes document at AuditLogRepository.cs:276-289 and OAuthAuthCodeRepository.cs:53-65); every production UpdatedAt writer stamps DateTimeOffset.UtcNow, so a +00:00 cutoff makes the SQLite TEXT compare at line 541 equal chronological order, and the LINQ branch at 551 compares by instant regardless; the regression is genuine (pre-fix the +02:00 cutoff binds as text that exceeds both rows, so both return and .Should().Equal(stale.Id) fails); WithSqliteRepoAsync builds a fresh temp-file DB per test; the sole caller (LlmQueueToProposalWorker.cs:180) already passes UTC, so shipped behavior is unchanged and the body does not claim otherwise; <=, ORDER BY, LIMIT and every other method untouched; interpolation stays parameterized via FromSqlInterpolated.

Findings and disposition (both LOW, none owed for merge):

• LOW, LlmQueueRepositoryIntegrationTests.cs:634: the test name ..._ComparesByInstant is broader than what is proved (cutoff normalized to +00:00 before a TEXT compare against +00:00 rows).
• LOW, LlmQueueRepository.cs:528-533: the comment is thinner than the sibling #1403 sites and does not say why the normalization is needed.

Issue disposition: slice of #1422. Still unnormalized and recorded on the issue: OutboundWebhookDeliveryRepository.cs:31, 92; LlmUsageRecordRepository.cs:130, 141, 146, 151, 167, 176, 185 (the caller-supplied {now} at 136 is also written into CreatedAt/UpdatedAt); the five caller-supplied UpdatedAt = {expectedUpdatedAt} equality claims in LlmQueueRepository.cs:619, 657, 682, 716, 736.