Panel login: correlate the poll result with the exact request id once the worker echoes it

[wisdommen]

Summary

The panel magic-link poll (LoginService.startAuthPolling / GET {api-url}/auth/magic-link/poll?playerUuid=...) is scoped only by playerUuid, and its response carries no field identifying which magic-link request completed. This module tracks a local requestId per pending request and threads it through its own callbacks (handlePanelPollCompleted, completePanelLogin), but that id never round-trips through the UltiPanel worker -- the worker is never asked about a specific request, only "is there a completed status for this player".

Reproduction (logical, not yet exploited on a live worker)

1. Player runs /panel. Local request A is created and published; startAuthPolling begins polling for player-scoped completion, tracking request A's id locally.
2. An admin runs a credential-changing action (resetPassword, changePassword, unregister) on the same player. invalidateSession bumps the local invalidation generation and cancels request A's local bookkeeping (pendingPanelRequests entry + polling task) via cancelPendingPanelRequest. The remote magic link the worker issued for request A is not told to stop being valid -- there is no worker-side revoke call in this flow.
3. The player runs /panel again. Local request B is created and published; a new poll starts, tracking request B's id locally.
4. If the still-live remote link for request A is completed (e.g. a stale browser tab, an already-opened magic-link email/notification, or simple race with however long the worker keeps A pending), request B's poll -- which only ever asks the worker "is anything completed for this playerUuid" -- observes that completion and calls completePanelLogin(B, ...), authenticating through B's local bookkeeping even though the underlying confirmation was actually A's.

Why this module cannot close it alone

Every prior round of hardening on PR #18 (generation fencing before publish, atomic check-and-insert under a per-player lock, a post-POST re-check, isPanelRequestCurrent on the main-thread result-delivery callback, and request-id-keyed local pendingPanelRequests lookups in handlePanelPollCompleted) closes races in this module's own bookkeeping between a local invalidation and a local publish/poll/callback. None of them can close this specific gap, because it is not a local race -- it is that the remote poll response itself carries no way to distinguish which request completed. Closing it requires changes on the UltiPanel worker side; see the companion issue in UltiKits/ultipanel-api-worker.

Proposed direction (for this repository, once the worker side lands)

Once the worker returns and accepts a per-request id/nonce:

• requestPanelLink's create call already generates and sends a requestId -- keep doing so, but expect the worker to echo it back (or accept it) on poll/completion.
• startAuthPolling should scope its poll by that id (query param or request body), not just playerUuid.
• handlePanelPollCompleted/completePanelLogin should verify the returned id matches the one this poll was started for before granting anything -- current local-id checks would then also be validated against the remote response, not just against this module's own map.

Context

• Found during Codex PR fix(13-06,13-13): session invalidation, email-service crash, and recovery-command reachability #18 review (round 10), thread fix(13-06,13-13): session invalidation, email-service crash, and recovery-command reachability #18 (comment).
• Related local hardening: LoginService.invalidateSession, requestPanelLink(Player, long), isPanelRequestCurrent, handlePanelPollCompleted -- see LoginService.java in this repository for the full history of local-race fixes this gap sits behind.
• Companion issue (worker side): UltiKits/ultipanel-api-worker#36

[wisdommen]

Maintainer decision (2026-09-07): scheduled for the next milestone, not 6.3.0. 6.3.0 is a correctness-and-consolidation release and this change alters the create/poll contract between UltiLogin and the UltiPanel worker (per-request id returned and accepted; pending requests revoked on credential invalidation), so it is planned together with the worker's next milestone. UltiLogin's local mitigations (invalidation generation checked before and after the request, request-id-keyed polling, main-thread revalidation) shipped in #18.

[wisdommen]

Maintainer decision, recorded by agent (Phase 15, plan 15-20).

The maintainer was asked to reconfirm the existing 2026-09-07 decision on this issue (scheduled for
the next milestone, not 6.3.0, since 6.3.0 is a correctness-and-consolidation release and this
change alters the create/poll contract between UltiLogin and the worker). The agenda's
recommendation was to record this as settled by that existing decision and close it on that basis —
no fresh answer was needed for this specific item.

Verbatim decision (Chinese, the decision of record): 「维持 2026-09-07 的决定，记为已决（推荐）」
English gloss (a rendering of the decision, not a substitute for it): "Uphold the 2026-09-07
decision; record it as already settled (the recommended option)."
Date: 2026-09-12 local time (maintainer's machine, UTC+10) / approximately 2026-09-11T17:2xZ UTC.
Register entry: /home/wisdomme/servers/evidence/phase-15/15-DEFECT-REGISTER.md (Phase 15 local
evidence); full context in /home/wisdomme/servers/evidence/phase-15/15-ADJUDICATION.md, item 6.

A maintainer made this decision; an agent recorded it on their behalf. This is a formal
re-confirmation of the existing 2026-09-07 decision already on this issue (quoted above), not a
fresh adjudication.

Disposition: closed, citing the existing 2026-09-07 comment as the written decision. 6.3.0 ships
accepting the narrow race window this issue describes, which this module's own local safeguards
(matching pending requests by their own tracking number, re-checking on the main server thread
before finalizing, and invalidating stale sessions) substantially reduce without eliminating.