The LoTW/QRZ confirmation download ran on the app-lifetime context, so it
kept going after the QSL Manager was closed and a new download didn't stop the
previous one. A slow QRZ sync therefore bled its "flag cleared" log into a
freshly started LoTW download — the operator saw QRZ activity during a LoTW
run. Now each download gets a cancellable context: starting one cancels the
previous, closing the window cancels it (CancelConfirmations), and the parse
loops bail promptly on cancel. (A LoTW http 503 is separate — ARRL's server.)
1. A language change rebuilt the column defs, which sets the anti-clobber
guard, but the effect that clears it listened to only two of the rebuild's
causes. Guard stuck on → every column change was silently discarded for the
rest of the session. Now keyed on the rebuilt defs themselves, so any future
cause is covered.
2. The cluster grid had no guard at all: the same rebuild wrote its defaults
over the saved layout, in the cache AND the database. Unrecoverable.
3. Worked-before and cluster read their state before the active profile was
known, so they looked up the unscoped cache key (always a miss) and then
saved under the scoped one. They now wait for the scope and remount on a
profile switch, like the main log.
4. GetUIPref returns an ERROR, not "", while the settings store is not yet
scoped — deliberately distinct from "unset". The frontend read it as "no
preference", rendered defaults, and the first column event overwrote the
good copy. It now retries instead of giving up.
5. The QSL manager had no storageKey, so it shared the main log's layout and
each rewrote the other.
Also: the DB write is debounced (a resize drag fired dozens of writes) with a
flush on close, and a rejected write is retried rather than dropped.
rouggy
