fix(stalker): prefer the live playlist row over a stale favorite snapshot

Codex P1 on #1364, and mine. `resolveStalker` reads its portal coordinates as
`item.stalkerPortalUrl ?? playlist?.portalUrl` — item first. The create_link
branch quietly corrected for that afterwards by re-reading
`applyOverride(playlist).portalUrl`, so the row won wherever it existed, which
is what the comment right above it already promised: "when the row exists it
wins over the item's snapshot of the portal URL (a repaired endpoint must beat
a stale favorite)". The static branch I added returns before that correction,
so it shipped the stale snapshot.

Consequences after a playlist edit: a same-host static URL matching the OLD
host gets the newly negotiated token and identity headers sent to the previous
portal, and a MAC-only edit pairs the new token with the old MAC cookie —
precisely the pairing `stalkerIdentityFingerprint` exists to prevent.

Both branches now derive the coordinates once, row-first with the repair
override applied, and fall back to the item's snapshot only for a playlist
that no longer exists — which is the role `buildStalkerPlayback` already
documents for it. Mutation-checked: restoring item-first precedence fails the
new test alone.

Also documents a local-only e2e hazard found while re-running the suite:
`mode: 'serial'` orders tests within one project, but chromium/firefox/webkit
run the file concurrently against the same mock server, so one project's
beforeEach reset can drop a session another is mid-test on — which is what a
lone auth-spec failure that passes on rerun actually is. CI never sees it; the
Web E2E job runs --project=chromium alone, and that command is clean (22/22).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

apps/web-e2e/src/stalker.e2e.ts

@@ -38,6 +38,16 @@ import {
  *
  * Giving each test its own MAC instead would mean inventing a scenario per
  * test; serializing one file is the cheaper trade.
+ *
+ * ACROSS BROWSER PROJECTS this does NOT hold, and it is a local-run hazard
+ * only. `mode: 'serial'` orders tests within one project; chromium, firefox
+ * and webkit still run the file concurrently against the SAME mock server, so
+ * one project's `beforeEach` reset can drop a session another project is
+ * mid-test on — the auth specs below are the ones that notice, failing as if
+ * the portal had dropped them. CI never sees it: the Web E2E job runs
+ * `--project=chromium` alone (`.github/workflows/e2e-tests.yaml`). If a local
+ * all-project run shows a lone auth failure that passes on rerun, this is why;
+ * `--project=chromium` reproduces CI exactly.
  */
 
 test.describe.configure({ mode: 'serial' });