fix(web): guard request-status-card against undefined deployRequest

[benhegartysefe]

Problem

The Monitor result page throws a console error on load:

Uncaught (in promise) TypeError: can't access property "Log", this.deployRequest is undefined
    render index-...js:16840

Root cause — a render race

page-monitor-result.ts kicks off three parallel subscriptions (request status, result statuses, attempts) and flips loading to false in each subscription's complete callback. The result-statuses and attempts calls routinely finish before the request call — visible in the console ordering (done loading result Statuses / done loading attempts arrive before done loading request). So <request-status-card> renders while deployRequest is still undefined.

request-status-card.ts then read this.deployRequest.Log (line 158) without optional chaining — the one access in the file that didn't use ?. — and threw, aborting the render. The <request-controls> bindings (lines 308–321) had the same unguarded pattern and would have thrown next once line 158 was fixed.

Fix

Add optional chaining to every deployRequest access in the render path, matching the convention already used throughout the rest of the file. The card now renders harmlessly until the request data arrives and the component self-heals on the next update.

• Cosmetic-but-noisy: the card eventually recovered, but the exception spammed the console and aborted a render pass on every load.
• npx tsc --noEmit is clean.

Scope

request-status-card.ts only — diff-local, no behavioural change once data is loaded.

🤖 Generated with Claude Code

[github-actions]

Test Results

0 tests  ±0   0 ✅ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit 8fd2600. ± Comparison against base commit 0f8f087.

♻️ This comment has been updated with latest results.