OpenEMR: identity check at 'Confirm Create New Patient' reads a background label behind the modal and refuses every 9-17 items #1347

What happens

On the OpenEMR referral program (DOM-identity bundle, engine b82131e from #1296), the identity check at step_040 (click "Confirm Create New Patient", inside OpenEMR's duplicate-check dialog) refuses about once every 9 to 17 items. Nothing is written. The worklist then stops and pauses the rest.

Evidence

From the halted item's report.json (std run, item 8):

step_040 Identity check failed ... a target was found positionally (rung 'structural', confidence 1.00)
but its surrounding text does not match the recorded target's — expected '<identity template>',
observed 'Emergency Contact: Confirm Create New Patient Cancel' (coverage 0.81) — refusing to act
identity: {"status": "mismatch", "mode": "context", "coverage": 0.8056, ...}
resolution: {"rung": "structural", "point": [600, 328], "confidence": 1.0, "candidate_count": 1}

The previous item in the same run (item 7) verified:

identity: {"status": "verified", "mode": "context", "coverage": 1.0,
           "observed": "County: Confirm Create New Patient Cancel"}

The fast run's halt (item 16) reads the same Emergency Contact: ... text at coverage 0.8056.

Likely cause

The context the identity check reads around the dialog's button includes a label from the form behind the modal: "County:" in healthy runs, "Emergency Contact:" in the halted ones. That label depends on where the form behind the dialog happens to be scrolled. The dialog itself (its title, button and Cancel) is the same in every run. The check is fail-closed and correct to refuse when the identity is unclear. But here its evidence includes background text that has nothing to do with which record is being saved.

To look at

• Whether the context window for a target inside a modal should be limited to the modal (its dialog or overlay container).
• Whether the recorded template for this step froze the background label.

The halted items' artifacts (report.json, host_load.json) are in the harness output, which isn't committed. The runs had --keep-pngs off, so no screenshots were kept. A rerun with --keep-pngs would capture them.

Reproduce: the throughput harness from #1296, --items 26 --workers 1 --speed standard, on the OpenEMR fixture.