Fetch the watchlist window the URL actually asked for

[ralyodio]

A shared link like /watchlist?range=1Y lit up the 1Y button and then showed 3M numbers underneath it. The table was wrong and said nothing about being wrong.

This is also why typecheck + bun test has been failing: dashboard-watchlist.test.ts asserted the deep-link case in #22 and it has never passed. The suite is green at 590 with this.

Two faults, one behind the other

The state was restored too late. restoreWatchlistPrefs() ran inside boot(), which reaches it only after awaiting /health and /api/stats — but the session resolving fires advis0r:auth-changed → openWatchlistTab() well before that. The first overview request therefore went out on the default 3M window, before the URL had been read at all. It is restored at module scope now, so nothing can read wlView before it reflects the URL.

Then the correction was dropped. When boot() caught up and asked for 1Y, loadWatchlistOverview returned early because a request was already in flight — so the right window was never fetched, and the 3M payload rendered under the 1Y label. Requests are coalesced now instead of discarded: the fetch loop re-runs while the selected range differs from the one just fetched, and the last write wins.

Two more paths through the same guard

• Clicking 1Y while the 3M request is still outstanding — dropped, same wrong-data-wrong-label result.
• Adding a ticker mid-request, which reprices the table — dropped, leaving the new row permanently unpriced.

The first is covered by the range check in the loop, the second by a pending flag. Both have a test that I verified fails without the fix (I reverted each half in turn and watched the corresponding test go red).

Verified

bun install --frozen-lockfile, bun run typecheck clean, bun test 590 pass / 0 fail — the same steps test.yml runs.

⚠️ CI itself still cannot run: every Actions job across these repos fails in 3–4s with "The job was not started because recent account payments have failed or your spending limit needs to be increased" and produces no logs. That is a billing action in GitHub settings, not something in the code — the checks on this PR will be red for that reason regardless of the change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WQQYeLjnzqv5n39KLu3gdK