Fix the picker timeout, loader requests cancelling each other, and unreadable rejections

[MathiasWP]

Three things from investigating a 403 on a Better Auth session cookie. None is the 403 itself — but two of them were making it harder to see, and the third is a bug found on the way.

1. "Pick credential…" timed out with a good cookie in hand

read_session reads localStorage first, which needs script evaluation, which fails until the page has loaded. The ? propagated that failure and threw away the cookie sweep with it — even though cookies come from the Rust side, need no script, and are readable the moment the window exists.

So clicking Pick credential… from a closed window reported "timed out reading the sign-in window"; opening the window first, then picking, worked.

The eval failure is now held and reported only if the cookie sweep also comes back empty. The retry loop in snapshot() needed a matching change or this would trade one bug for another: it stopped at the first non-empty read, and since cookies arrive before the page does, that would hand back a cookies-only snapshot the instant the window opened and miss a credential kept in localStorage. It now settles on a complete read, keeping a cookies-only one as the fallback.

Worst case drops from ~43s (eight attempts each waiting out a 5s eval timeout) to as soon as the page answers.

2. "request cancelled"

HttpState keys in-flight requests by RequestSpec::id, and HashMap::insert under an existing key drops the old cancel sender — which is precisely what the receiver is waiting on. Every loader request for a section shared one id, so any two that overlapped killed each other: a Fetch a sample while a background refresh was out, with timing deciding which died.

Nothing cancels a loader request by id — only the window does that, for requests a person sent — so it had no reason to be predictable. Each now gets a unique handle.

3. A rejection that came from a different host now says so

reqwest_strips (http.rs:357) lists cookie and authorization, so those credentials ride reqwest's own redirect policy — which drops them on a cross-host hop. A 403 after being redirected off-origin is a completely different problem from a 403 from your own API, and they looked identical.

LoaderResponse now carries the resolved request URL alongside the final one (the loader itself only holds the relative form), and a rejection reports the origin it ended up on. Compared by origin, not whole URL: a same-host redirect is ordinary and says nothing.

The sidebar's loader error is also selectable with a Copy button — "I'm not sure how to give you the exact error" is a bug report about this app, not about the person writing it.

Testing

cargo fmt --check, cargo clippy --no-default-features --all-targets -- -D warnings, cargo test (133 passed, 3 new: cross-host redirect note, same-origin redirect stays quiet, unique cancel handles), pnpm check (0 errors), pnpm test:e2e (316 passed).