explorer: #pid= deep-link populates the sidebar card but never opens the in-map detail card

[rdhyee]

Cross-refs: #239 (this is a specific, code-traced instance of that "interactive vs. cold-reload divergence" family), #226 (unified click semantics).

Symptom

Opening or sharing a #pid=… deep-link — on cold load or via a back/forward hashchange — populates the left sidebar detail (#clusterSection) but the floating in-map detail card (#inMapCard) that a normal row-click shows never appears, and the camera does not fly to the sample. The same pid reached two different ways (deep-link vs. row-click) lands in two different UI states.

Root cause (traced in explorer.qmd)

Row activation activateRow calls both updateSampleCard() and showInMapCard() + viewer.camera.flyTo() (lines ~2094–2113).

Both deep-link paths call only updateSampleCard():

• boot deep-link (lines ~5189–5215): sets selectedPid, calls updateSampleCard + updateSampleDetail; no showInMapCard / flyTo.
• hashchange handler (lines ~4048–4069): same omission.

Repro

1. Load explorer.html?<view params>#pid=<known-pid> (e.g. the OpenContext Object 5404-8 sample).
2. Observe: sidebar fills; no in-map card; camera stays put.
3. Compare: click that same row in the table → in-map card appears + camera flies to the sample.

Acceptance

• Deep-linking a pid reaches the same end state as a row-click (in-map card shown, camera framed) — or we make a deliberate decision that deep-links are sidebar-only and document the rationale.
• If we open the card: watch for the populateInMapCardDetail lazy-load race the Explorer: unify click semantics — click opens detail card, external link is one-hop-away #226 Codex review flagged — anchor the card at canvas centre exactly as activateRow does (the deferred-to-flyTo.complete approach was already rejected there).

Filed from the PR2 (#11) characterization follow-up; line numbers are against explorer.qmd at 1e27aa2.