LlmQueueRepository.TryClaimProcessingCaptureAsync bypasses EF change tracker (latent staleness)

[Chris0Jeky]

Context

Follow-up from PR #1200 review (gemini HIGH / codex P2 on TryClaimProcessingAsync).

TryClaimProcessingCaptureAsync in backend/src/Taskdeck.Infrastructure/Repositories/LlmQueueRepository.cs uses a raw-SQL UPDATE (bumps UpdatedAt) that bypasses the EF change tracker, same as TryClaimProcessingAsync did before PR #1200. Any tracked instance of the request in the same DbContext keeps the stale UpdatedAt after a successful claim.

Why it is latent, not active

Its only caller (LlmQueueToProposalWorker.ProcessCaptureTriageItemAsync) claims inside a fresh DI scope before fetching the entity, so no stale tracked instance exists today. There is no observable bug.

Suggested fix

Apply the same post-claim reload added to TryClaimProcessingAsync in PR #1200 (reload the _context.LlmRequests.Local instance via Entry(...).ReloadAsync() on success), and document the refresh contract on ILlmQueueRepository.TryClaimProcessingCaptureAsync, so future callers that fetch-then-claim in one context cannot regress.

Acceptance

• Post-claim reload in TryClaimProcessingCaptureAsync mirroring TryClaimProcessingAsync
• Refresh contract documented on the interface method
• Integration test: tracked capture request reflects the new UpdatedAt after a successful capture claim