fix(runtime): read each frame's viewport from the frame, not live from the backend

[abrichr]

Fixes #402.

The defect

The replayer resolved targets, and clamped postcondition template searches,
against an already-captured frame while reading self.backend.viewport
live at call time. If the window moved, resized, or the display rescaled
between the capture and the use, that frame was interpreted under geometry it
never had.

The consequence is our own headline failure mode, produced by our runtime
rather than by the application: a coordinate scaled by the wrong viewport lands
where the operator never demonstrated, and the screen still looks plausible.

The fix

A PNG carries its dimensions in its IHDR chunk, so a frame can always answer
for itself. No refactor, no new protocol, no plumbing:

viewport=_frame_viewport(screen_png)   # was: self.backend.viewport

Five sites, each rebound to the frame it evaluates:

line	frame
8812	screen_png
10844	before_png
11174	frame_png
12575	frame_png
13066	frame_png — postcondition search clamp

The four remaining self.backend.viewport reads have no frame in scope and
are correct as live reads. They are deliberately untouched.

Severity, stated honestly

Narrow. It requires a geometry change inside the window between capture and
use. No occurrence has been observed, and there are no external deployments.
This is a correctness gap, not a live incident.

Verification

• Full suite on this branch: 5336 passed, 49 skipped, 0 failed, 0 errors.
• The 78 tests that the related abandoned branch fails: all 78 pass here.

Provenance, and a claim I retracted

Found while recovering abandoned work from a scratch directory that was one
purge from deletion. That work (feat/atomic-frame-actuation-lease, 4,602
lines) contains the same idea inside a half-finished backend refactor which
fails 78 tests — on its own author's base as well as on main, so it arrived
broken. It stays parked; this PR extracts only the correct idea.

Issue #402 originally warned that binding the viewport without also reworking
region postconditions would trade a rare silent wrong action for a frequent
over-halt. I tested that and it is false; the retraction and the two
experiments are in the issue thread. The postcondition breakage on that branch
has a different, unisolated cause. This change stands alone.