Verify whether adapter-multiplayer-firebase exposes presence / onDisconnect

[htsukamoto5]

Phase 2 — BLOCKED on adapter-multiplayer-firebase publishing. Investigation, not a commitment to build.

None of the four vendored bundles has any presence or disconnect awareness. Verified by inspection: presence, heartbeat, and beforeunload each return zero matches across all four files. Participant entries are removed only on an explicit disconnect() call, so a closed tab simply leaves its entry behind.

That is why dropout detection currently has to be inferred from consecutive round timeouts rather than observed.

Why it is worth checking rather than assuming

Firebase RTDB has a native onDisconnect primitive, so the Firebase adapter plausibly does or easily could expose presence. If it does, dropout detection upgrades from "wait for two or three 60-second timeouts, then guess" to "the partner is gone, right now" — which is the difference between a good survivor experience and a merely tolerable one, and it also removes the ghost-pairing failure mode.

Work

• When the adapter is available, check whether it exposes presence / onDisconnect at all.
• If yes: upgrade the dropout abort path to use it, keeping the timeout counter as a fallback.
• If no: file upstream on jspsych/jspsych-multiplayer, since every dyadic study on this stack has this problem.
• Either way, record the finding in READINESS.md so the next person does not re-derive it.

Do not let the unblocked timeout-counter work wait on this.

See READINESS.md section 2 and the blocked-packages section.