0.26.1

⛔ LEAVING THE ENGINE OUT OF THE FILE WAS READ AS LEAVING IT OUT OF THE
BROWSER. WHO_A_BROWSER_IS keeps binary_path out of what a session writes
down, and that is right: it is a path on THIS machine, and a session carried to
another one must resolve an engine rather than insist on a path that means
nothing there. But a browser restored from that file was then declared with no
engine at all, so it came back on whatever the seal resolved instead of on the
one the person had named.

Not only a developer's problem. Somebody running aihawk ui --binary <their build> and reopening a session got browsers on a DIFFERENT engine than the one
they asked for, silently. On a locally built one - a seal with no published
assets - they got no browser at all, because there was nothing to download and
nothing to run.

Found by reading what the interface's own agent said while working: it reported
that the browsers had died and could not relaunch, and recovered by closing and
reopening every one of them under the same name. That works precisely because
browser_open goes through the launch plan and a restore does not, which is the
shape of the defect stated by the workaround.

The engine is a property of the PROCESS, so plan.engine_here() is the one
place that knows what this build was told to run, and both the launch plan and
the restore read it from there. Same shape as the system prompt that a saved
conversation used to carry back in place of the current one: the file says what
happened, the build says what it runs on.

Two known-bads, both killed: declare without the engine, and put binary_path
into what the session file saves - which would make a session that only opens
on the machine that wrote it.