Add tab title update progress messages

[iAndrea]

Overview

Added real-time status tracking and browser tab title updates during e-ink display refreshes to provide user feedback during long-running display updates (30-60+ seconds).

Problem

• Display refresh requests were synchronous and blocking, causing the browser to appear frozen
• Users had no visibility into refresh progress when switching browser tabs

Solution

1. Backend Changes:

   • Made /update_now endpoint asynchronous - returns immediately instead of blocking
   • Added status tracking system with states: idle, starting, updating, complete, error
   • Implemented /update_status polling endpoint for frontend to query current status
   • Added /reset_status endpoint for manual recovery from stuck states
   • Added concurrent request protection - rejects new updates while one is in progress (HTTP 409)

2. Frontend Changes:

   • Implemented status polling (every 2 seconds) that updates browser tab title with progress
   • Tab title indicators: ⏳ Starting... → 🔄 Updating... → ✓ Complete!
   • Status persists across page navigation using sessionStorage
   • Added client-side concurrent request blocking for immediate user feedback
   • Added 3-minute safety timeout to prevent stuck states
   • Emergency resetUpdateStatus() function available in browser console (in plugin or playlist view)

Status Flow

• User clicks "Update Now" → Request returns immediately
• Frontend begins polling status endpoint
• Backend progresses: starting → updating → complete → idle
• Tab title updates in real-time, visible even when on other tabs
• After completion, blocks new requests for 1 second, then resets to idle

[iAndrea]

I noticed a race condition problem during scheduled plugin...

1. Manual refresh requests during scheduled (playlist) refreshes were not properly blocked
2. Condition lock was held for entire refresh duration (30-60+ seconds), causing manual requests to hang/block
3. When lock was finally released, manual requests would proceed even though a refresh had just completed
4. Frontend couldn't distinguish between scheduled background refreshes and its own manual requests, causing state inconsistency

Solution

1. Backend Changes:

• Added refresh_type tracking: "manual" for user-initiated updates, "scheduled" for automatic playlist refreshes
• Released condition lock immediately after determining refresh action (before long-running operations)
• Modified /update_status endpoint to return both status and refresh type: {"status": "updating", "refresh_type": "manual"}
• Manual requests now get immediate rejection (no hanging) when any refresh is in progress

2. Frontend Changes:

• Frontend polling now filters by refresh_type, only tracking "manual" requests
• Ignores scheduled/background refreshes completely to prevent false completion detection
• Tab title and progress indicators only update for user-initiated manual refreshes