fix(web): stop the import overlay lying to established users, name the account

[tyler-dane]

Summary

An established user's routine background catch-up and a brand-new account's first-ever import both collapse to the same aggregate IMPORTING product state. The week/day grid's empty-week overlay only checked that aggregate state, so a long-established user viewing a genuinely empty week during ordinary catch-up saw "Importing from Google..." as if this were a fresh connection — the exact misleading-state bug getSidebarSyncStatus's lastHealthyAt distinction already exists to prevent, just not reused here.

• Extracts that distinction into isFirstImportInProgress() and gates the grid overlay on it, so it only shows during an account's actual first import (Week's Grid.tsx and Day's DayCalendarGrid.tsx).
• Softens the overlay's copy, which promised results "within a minute" unconditionally — true for a small calendar, false for a large one — to something that doesn't overpromise a timeline, and fixes a stray em-dash in the same string.
• The sidebar's collapsed one-line status never named which account a reconnect problem belonged to (unlike Settings, where every account gets its own row with its email visible). getSidebarSyncStatus's reconnect-required text now includes the account's email when one is available; Settings' own getGoogleSyncStatus is untouched since it doesn't need it.

Last of the fixes from a pre-launch sync stability + UX audit (first: #2728, second: #2729, third: #2731, fourth: #2732).

Test plan

• New tests: isFirstImportInProgress (6 cases covering the exact routine-catchup-vs-first-import distinction), reconnect-status text with/without an account email
• Updated 1 existing test whose expectation intentionally changed (reconnect text now names the account)
• Full web suite: 2044 pass, 0 fail
• Full repo bun run type-check — clean
• biome check on all touched files — clean

🤖 Generated with Claude Code